draft-ietf-ace-key-groupcomm-04.txt   draft-ietf-ace-key-groupcomm-05.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: July 18, 2020 RISE AB Expires: September 10, 2020 RISE AB
January 15, 2020 March 09, 2020
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-04 draft-ietf-ace-key-groupcomm-05
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 July 18, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7
3.2. Authorization Response . . . . . . . . . . . . . . . . . 8 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9
4. Keying Material Provisioning and Group Membership Management 12 4. Keying Material Provisioning and Group Membership Management 13
4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 13 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 14
4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 23 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 26
4.3. Retrieval of Updated Keying Material . . . . . . . . . . 24 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 27
4.4. Retrieval of New Keying Material . . . . . . . . . . . . 26 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 28
4.5. Retrieval of Public Keys for Group Members . . . . . . . 26 4.5. Retrieval of Public Keys and Roles for Group Members . . 29
4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 27 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 30
4.7. Retrieval of Keying Material Version . . . . . . . . . . 27 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 31
4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 28 4.8. Retrieval of Keying Material Version . . . . . . . . . . 31
5. Removal of a Node from the Group . . . . . . . . . . . . . . 28 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 31
6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 29 5. Removal of a Node from the Group . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 33
7.1. Update of Keying Material . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 31 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 36
8.1. Media Type Registrations . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 33 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 36
8.3. ACE Authorization Server Request Creation Hints Registry 33 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 37
8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 34 8.3. ACE Authorization Server Request Creation Hints Registry 37
8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 34 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 38
8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 35 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 39
8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 36 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 39
8.8. Sequence Number Synchronization Method Registry . . . . . 36 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 40
8.9. Expert Review Instructions . . . . . . . . . . . . . . . 37 8.8. Sequence Number Synchronization Method Registry . . . . . 41
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.9. Expert Review Instructions . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 38 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . 39 9.1. Normative References . . . . . . . . . . . . . . . . . . 42
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Requirements on Application Profiles . . . . . . . . 41 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 43 Appendix A. Requirements on Application Profiles . . . . . . . . 45
B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 43 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 47
B.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 43 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 47
B.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 43 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 48
B.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 44 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- multicast [I-D.dijk-core-groupcomm-bis] or on publishing-subscribing
subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR
on CBOR [RFC7049], so CBOR is the format used in this specification. [RFC7049], so CBOR is the format used in this specification.
However, using JSON [RFC8259] instead of CBOR is possible, using the However, using JSON [RFC8259] instead of CBOR is possible, using the
conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. conversion method specified in Sections 4.1 and 4.2 of [RFC7049].
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, updated If the application requires backward and forward security, new keying
keying material is generated and distributed to the group members material is generated and distributed to the group upon membership
(rekeying), when membership changes. A key management scheme changes. A key management scheme performs the actual distribution of
performs the actual distribution of the updated keying material to the new keying material to the group. In particular, the key
the group. In particular, the key management scheme rekeys the management scheme rekeys the current group members when a new node
current group members when a new node joins the group, and the joins the group, and the remaining group members when a node leaves
remaining group members when a node leaves the group. Rekeying the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094]
mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. and [RFC2627].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
skipping to change at page 5, line 21 skipping to change at page 5, line 21
providing it with the group keying material to communicate with providing it with the group keying material to communicate with
the other group members (Section 4). the other group members (Section 4).
o A node to leave the group of for the KDC to remove a current o A node to leave the group of for the KDC to remove a current
member of the group (Section 5). member of the group (Section 5).
o Retrieving keying material as a current group member (Section 4.3 o Retrieving keying material as a current group member (Section 4.3
and Section 4.4). and Section 4.4).
o Renewing and re-distributing the group keying material (rekeying) o Renewing and re-distributing the group keying material (rekeying)
upon a membership change in the group (Section 4.8 and Section 5). upon a membership change in the group (Section 4.9 and Section 5).
Figure 2 provides a high level overview of the message flow for a Figure 2 provides a high level overview of the message flow for a
node joining a group communication setting, which can be expanded as node joining a group communication setting, which can be expanded as
follows. follows.
1. The joining node requests an Access Token from the AS, in order 1. The joining node requests an Access Token from the AS, in order
to access a specific group-membership resource on the KDC and to access a specific group-membership resource on the KDC and
hence join the associated group. The joining node will start or hence join the associated group. The joining node will start or
continue using a secure communication association with the KDC, continue using a secure communication association with the KDC,
according to the response from the AS. according to the response from the AS.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
the /authz-info endpoint at the KDC. After that, a joining node the /authz-info endpoint at the KDC. After that, a joining node
MUST have a secure communication association established with the MUST have a secure communication association established with the
KDC, before starting to join a group under that KDC. Possible KDC, before starting to join a group under that KDC. Possible
ways to provide a secure communication association are DTLS ways to provide a secure communication association are DTLS
[RFC6347] and OSCORE [RFC8613]. [RFC6347] and OSCORE [RFC8613].
3. The joining node starts the joining process to become a member of 3. The joining node starts the joining process to become a member of
the group, by accessing the related group-membership resource at the group, by accessing the related group-membership resource at
the KDC. At the end of the joining process, the joining node has the KDC. At the end of the joining process, the joining node has
received from the KDC the parameters and keying material to received from the KDC the parameters and keying material to
securely communicate with the other members of the group. securely communicate with the other members of the group, and the
KDC has stored the association between the authorization
information from the access token and the secure session with the
client.
4. The joining node and the KDC maintain the secure association, to 4. The joining node and the KDC maintain the secure association, to
support possible future communications. These especially include support possible future communications. These especially include
key management operations, such as retrieval of updated keying key management operations, such as retrieval of updated keying
material or participation to a group rekeying process. material or participation to a group rekeying process.
C AS KDC Group C AS KDC Group
| | | Member | | | Member
/ | | | | / | | | |
| | Authorization Request | | | | | Authorization Request | | |
Defined | |---------------------------->| | | Defined | |-------------------------->| | |
in the | | | | | in the | | | | |
ACE | | Authorization Response | | | ACE | | Authorization Response | | |
framework | |<----------------------------| | | framework | |<--------------------------| | |
| | | | | | | |
\ |----------- Token Post ---------->| | \ |---------- Token Post --------->| |
| | | | | |
|-------- Joining Request -------->| | |------- Joining Request ------->| |
| | | | | |
|<------- Joining Response --------|-- Group Rekeying -->| |<------ Joining Response -------|-- Group Rekeying -->|
| | | | | |
| Dispatcher | | Dispatcher |
| | | | | |
|<====== Secure group communication ========|===========>| |<===== Secure group communication =======|===========>|
| | | | | |
Figure 2: Message Flow Upon New Node's Joining Figure 2: Message Flow Upon New Node's Joining
The exchange of Authorization Request and Authorization Response The exchange of Authorization Request and Authorization Response
between Client and AS MUST be secured, as specified by the transport between Client and AS MUST be secured, as specified by the transport
profile of ACE used between Client and KDC. profile of ACE used between Client and KDC.
The exchange of Joining Request and Joining Response between Client The exchange of Joining Request and Joining Response between Client
and KDC MUST be secured, as a result of the transport profile of ACE and KDC MUST be secured, as a result of the transport profile of ACE
used between Client and KDC. used between Client and KDC.
skipping to change at page 7, line 36 skipping to change at page 7, line 38
Figure 3: Message Flow of Join Authorization Figure 3: Message Flow of Join Authorization
3.1. Authorization Request 3.1. Authorization Request
The Authorization Request sent from the Client to the AS is as The Authorization Request sent from the Client to the AS is as
defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY
contain the following parameters, which, if included, MUST have the contain the following parameters, which, if included, MUST have the
corresponding values: corresponding values:
o 'scope', containing the identifier of the specific group (or topic o 'scope', containing the identifier of the specific group(s), or
in the case of pub-sub) that the Client wishes to access, and topic(s) in the case of pub-sub, that the Client wishes to access,
optionally the role(s) that the Client wishes to take. This value and optionally the role(s) that the Client wishes to take.
is a CBOR array encoded as a byte string, which contains:
This value is a CBOR byte string, encoding a CBOR array of one or
more entries.
An entry has as value a CBOR array, which contains:
* As first element, the identifier of the specific group or * As first element, the identifier of the specific group or
topic. topic.
* Optionally, as second element, the role (or CBOR array of * Optionally, as second element, the role (or CBOR array of
roles) the Client wishes to take in the group. roles) that the Client wishes to take in the group. This
element is optional since roles may have been pre-assigned to
the Client, as associated to its verifiable identity
credentials. Alternatively, the application may have defined a
single, well-known role for the target resource(s) and
audience(s).
The encoding of the group or topic identifier (REQ1) and of the In each entry, the encoding of the group or topic identifier
role identifiers (REQ2) is application specific, and part of the (REQ1) and of the role identifiers (REQ2) is application specific,
requirements for the application profile. and part of the requirements for the application profile.
In particular, the application profile may specify CBOR values to
use for abbreviating role identifiers (OPT7).
An example of CDDL definition of scope, with group identifier
encoded as byte string and role identifier as text string, is
given in Figure 4.
o 'audience', with an identifier of a KDC. o 'audience', with an identifier of a KDC.
o 'req_cnf', as defined in Section 3.1 of o 'req_cnf', as defined in Section 3.1 of
[I-D.ietf-ace-oauth-params], optionally containing the public key [I-D.ietf-ace-oauth-params], optionally containing the public key
or a reference to the public key of the Client, if it wishes to or a reference to the public key of the Client, if it wishes to
communicate that to the AS. communicate that to the AS.
o Other additional parameters as defined in o Other additional parameters as defined in
[I-D.ietf-ace-oauth-authz], if necessary. [I-D.ietf-ace-oauth-authz], if necessary.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" defined in Section 8.14 of "application/ace+cbor" defined in Section 8.14 of
[I-D.ietf-ace-oauth-authz] is used. [I-D.ietf-ace-oauth-authz] is used.
scp = [ gid : bstr , ? ( role: tstr / [ 2*role ] ) ]
scope = << [ + scp ] >>
Figure 4: CDDL example of scope, with group identifier encoded as
bstr and role as tstr
3.2. Authorization Response 3.2. Authorization Response
The Authorization Response sent from the AS to the Client is as The Authorization Response sent from the AS to the Client is as
defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST
contain the following parameters: contain the following parameters:
o 'access_token', containing the proof-of-possession access token. o 'access_token', containing the proof-of-possession access token.
o 'cnf' if symmetric keys are used, not present if asymmetric keys o 'cnf' if symmetric keys are used, not present if asymmetric keys
are used. This parameter is defined in Section 3.2 of are used. This parameter is defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of-
possession key that the Client is supposed to use with the KDC. possession key that the Client is supposed to use with the KDC.
o 'rs_cnf' if asymmetric keys are used, not present if symmetric o 'rs_cnf' if asymmetric keys are used, not present if symmetric
keys are used. This parameter is as defined in Section 3.2 of keys are used. This parameter is as defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains information about the [I-D.ietf-ace-oauth-params] and contains information about the
public key of the KDC. public key of the KDC.
o 'exp', contains the lifetime in seconds of the access token. This o 'expires_in', contains the lifetime in seconds of the access
parameter MAY be omitted if the application defines how the token. This parameter MAY be omitted if the application defines
expiration time is communicated to the Client via other means, or how the expiration time is communicated to the Client via other
if it establishes a default value. means, or if it establishes a default value.
Additionally, the Authorization Response MAY contain the following Additionally, the Authorization Response MAY contain the following
parameters, which, if included, MUST have the corresponding values: parameters, which, if included, MUST have the corresponding values:
o 'scope', which mirrors the 'scope' parameter in the Authorization o 'scope' containing the granted scope, if different from the scope
Request (see Section 3.1). Its value is a CBOR array encoded as a requested by the client. This parameter has the same format and
byte string, containing: encoding of 'scope' in the Authorization Request, defined in
Section 3.1.
* As first element, the identifier of the specific group or topic
the Client is authorized to access.
* Optionally, as second element, the role (or CBOR array of
roles) the Client is authorized to take in the group.
The encoding of the group or topic identifier and of the role
identifiers is the same as in Section 3.1.
o Other additional parameters as defined in o Other additional parameters as defined in
[I-D.ietf-ace-oauth-authz], if necessary. [I-D.ietf-ace-oauth-authz], if necessary.
The access token MUST contain all the parameters defined above The access token MUST contain all the parameters defined above
(including the same 'scope' as in this message, if present, or the (including the same 'scope' as in this message, if present, or the
'scope' of the Authorization Request otherwise), and additionally 'scope' of the Authorization Request otherwise), and additionally
other optional parameters that the transport profile of ACE requires. other optional parameters that the transport profile of ACE requires.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in As in [I-D.ietf-ace-oauth-authz], these parameters are included in
skipping to change at page 10, line 36 skipping to change at page 11, line 10
Optionally, if they were included in the request, the KDC MAY include Optionally, if they were included in the request, the KDC MAY include
the 'sign_info' parameter as well as the 'pub_key_enc' parameter the 'sign_info' parameter as well as the 'pub_key_enc' parameter
defined in Section 3.3.1 and Section 3.3.2 of this specification, defined in Section 3.3.1 and Section 3.3.2 of this specification,
respectively. respectively.
The 'sign_info' parameter MUST be present if the POST request The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter with value Null. If present, the included the 'sign_info' parameter with value Null. If present, the
'sign_info' parameter of the 2.01 (Created) response is a CBOR array 'sign_info' parameter of the 2.01 (Created) response is a CBOR array
formatted as follows. formatted as follows.
TODO: have 'sign_info' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
o The first element 'sign_alg' is an integer or a text string, o The first element 'sign_alg' is an integer or a text string,
indicating the signature algorithm used in the group. It is indicating the signature algorithm used in the group. It is
REQUIRED of the application profiles to define specific values for REQUIRED of the application profiles to define specific values
this parameter (REQ3). that this parameter can take (REQ3), selected from the set of
signing algorithms of the COSE Algorithms registry defined in
[RFC8152].
o The second element 'sign_parameters' indicates the parameters of o The second element 'sign_parameters' indicates the parameters of
the signature algorithm. Its structure depends on the value of the signature algorithm. Its structure depends on the value of
'sign_alg'. It is REQUIRED of the application profiles to define 'sign_alg'. It is REQUIRED of the application profiles to define
specific values for this parameter (REQ4). If no parameters of specific values for this parameter (REQ4). If no parameters of
the signature algorithm are specified, 'sign_parameters' MUST be the signature algorithm are specified, 'sign_parameters' MUST be
encoded as the CBOR simple value Null. encoded as the CBOR simple value Null.
o The third element 'sign_key_parameters' indicates the parameters o The third element 'sign_key_parameters' indicates the parameters
of the key used with the signature algorithm. Its structure of the key used with the signature algorithm. Its structure
skipping to change at page 11, line 14 skipping to change at page 11, line 42
algorithm are specified, 'sign_key_parameters' MUST be encoded as algorithm are specified, 'sign_key_parameters' MUST be encoded as
the CBOR simple value Null. the CBOR simple value Null.
The 'pub_key_enc' parameter MUST be present if the POST request The 'pub_key_enc' parameter MUST be present if the POST request
included the 'pub_key_enc' parameter with value Null. If present, included the 'pub_key_enc' parameter with value Null. If present,
the 'pub_key_enc' parameter of the 2.01 (Created) response is either the 'pub_key_enc' parameter of the 2.01 (Created) response is either
a CBOR integer indicating the encoding of public keys used in the a CBOR integer indicating the encoding of public keys used in the
group, or has value Null indicating that the KDC does not act as group, or has value Null indicating that the KDC does not act as
repository of public keys for group members. repository of public keys for group members.
TODO: have 'pub_key_enc' as an array, if 'scope' in the Access Token
covers multiple groups/topics.
Its acceptable values are taken from the "CWT Confirmation Method" Its acceptable values are taken from the "CWT Confirmation Method"
Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is
REQUIRED of the application profiles to define specific values to use REQUIRED of the application profiles to define specific values to use
for this parameter (REQ6). for this parameter (REQ6).
The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters
formatted as in the response is given below. formatted as in the response is given below.
sign_info_res = [ sign_info_res = [
sign_alg : int / tstr, sign_alg : int / tstr,
skipping to change at page 13, line 13 skipping to change at page 13, line 42
or missed group rekeying. This is described in Section 4.3. or missed group rekeying. This is described in Section 4.3.
o The Client can retrieve a new individual key, or new input o The Client can retrieve a new individual key, or new input
material to derive it. This is described in Section 4.4. material to derive it. This is described in Section 4.4.
o The Client can (re-)get the public keys of other group members, o The Client can (re-)get the public keys of other group members,
e.g. if it is aware of new nodes joining the group after itself. e.g. if it is aware of new nodes joining the group after itself.
This is described in Section 4.5. This is described in Section 4.5.
o The Client can (re-)get the policies currently enforced in the o The Client can (re-)get the policies currently enforced in the
group. This is described in Section 4.6. group. This is described in Section 4.7.
o The Client can (re-)get the version number of the keying material o The Client can (re-)get the version number of the keying material
currently used in the group. This is described in Section 4.7. currently used in the group. This is described in Section 4.8.
o The Client can request to leave the group. This is further o The Client can request to leave the group. This is further
discussed in Section 4.8. discussed in Section 4.9.
Upon receiving a request from a Client, the KDC MUST check that it is Upon receiving a request from a Client, the KDC MUST check that it is
storing a valid access token from that Client for the group storing a valid access token from that Client for the group
identifier assiciated to the endpoint. If that is not the case, i.e. identifier assiciated to the endpoint. If that is not the case, i.e.
the KDC does not store a valid access token or this is not valid for the KDC does not store a valid access token or this is not valid for
that Client for the group identifier at hand, the KDC MUST respond to that Client for the group identifier at hand, the KDC MUST respond to
the Client with a 4.01 (Unauthorized) error message. the Client with a 4.01 (Unauthorized) error message.
4.1. Interface at KDC 4.1. Interface at the KDC
The KDC is configured with the following resources: The KDC is configured with the following resources:
o /ace-group : this resource is fixed and indicates that this o /ace-group : this resource is fixed and indicates that this
specification is used. Other applications that run on a KDC specification is used. Other applications that run on a KDC
implementing this specification MUST NOT use this same resource. implementing this specification MUST NOT use this same resource.
o /ace-group/gid : one sub-resource to /ace-group is implemented for o /ace-group/GROUPNAME : one sub-resource to /ace-group is
each group the KDC manages. These resources are identified by the implemented for each group the KDC manages. These resources are
group identifiers of the groups the KDC manages (in this example, identified by the group identifiers of the groups the KDC manages
the group identifier has value "gid"). These resources support (in this example, the group identifier has value "GROUPNAME").
GET and POST method. These resources support GET and POST method.
o /ace-group/gid/pub-key : this sub-resource is fixed and supports o /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and
GET and FETCH methods. supports GET and FETCH methods.
o /ace-group/gid/policies: this sub-resource is fixed and supports o /ace-group/GROUPNAME/policies: this sub-resource is fixed and
the GET method. supports the GET method.
o /ace-group/gid/ctx-num: this sub-resource is fixed and supports o /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and
the GET method. supports the GET method.
o /ace-group/gid/node: one sub-resource to /ace-group/gid is o /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
implemented for each node in the group the KDC manages. These group/GROUPNAME is implemented for each node in the group the KDC
resources are identified by the node name (in this example, the manages. These resources are identified by the node name (in this
node name has value "node"). These resources support GET, PUT and example, the node name has value "NODENAME"). These resources
DELETE methods. support GET, PUT and DELETE methods.
o /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to
/ace-group/GROUPNAME/nodes/NODENAME is implemented for each node
in the group the KDC manages. These resources are identified by
the node name (in this example, the node name has value
"NODENAME"). These resources support the POST method.
The details for the handlers of each resource are given in the The details for the handlers of each resource are given in the
following sections. These endpoints are used to perform the following sections. These endpoints are used to perform the
operations introduced in Section 4. Note that the url-path given operations introduced in Section 4. Note that the url-path given
here are default names: implementations are not required to use these here are default names: implementations are not required to use these
names, and can define their own instead. names, and can define their own instead.
4.1.1. ace-group 4.1.1. ace-group
No handlers are implemented for this resource. No handlers are implemented for this resource.
4.1.2. ace-group/gid 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 "gid". material for the group identified by "GROUPNAME".
The handler expects a request with payload formatted as a CBOR map The handler expects a request with payload formatted as a CBOR map
which MAY contain the following fields, which, if included, MUST have which MAY contain the following fields, which, if included, MUST have
the corresponding values: the corresponding values:
o 'scope', with value the specific resource that the Client is o 'scope', with value the specific resource that the Client is
authorized to access (i.e. group or topic identifier) and role(s), authorized to access, i.e. group or topic identifier, and role(s).
encoded as in Section 3.1. This value is a CBOR byte string encoding one scope entry, as
defined in Section 3.1.
o 'get_pub_keys', if the Client wishes to receive the public keys of o 'get_pub_keys', if the Client wishes to receive the public keys of
the other nodes in the group from the KDC. The value is an empty the other nodes in the group from the KDC. The value is an empty
CBOR array. This parameter may be present if the KDC stores the CBOR array. This parameter may be present if the KDC stores the
public keys of the nodes in the group and distributes them to the public keys of the nodes in the group and distributes them to the
Client; it is useless to have here if the set of public keys of Client; it is useless to have here if the set of public keys of
the members of the group is known in another way, e.g. it was the members of the group is known in another way, e.g. it was
provided by the AS. provided by the AS.
o 'client_cred', with value the public key or certificate of the o 'client_cred', with value the public key or certificate of the
skipping to change at page 15, line 33 skipping to change at page 16, line 23
own private key, whose corresponding public key is either directly own private key, whose corresponding public key is either directly
specified in the 'client_cred' parameter or included in the specified in the 'client_cred' parameter or included in the
certificate specified in the 'client_cred' parameter. certificate specified in the 'client_cred' parameter.
o 'pub_keys_repos', can be present if a certificate is present in o 'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value the URI of the certificate of the 'client_cred' field, with value the URI of the certificate of
the Client. This parameter is encoded as a CBOR text string. the Client. This parameter is encoded as a CBOR text string.
Alternative specific encodings of this parameter MAY be defined in Alternative specific encodings of this parameter MAY be defined in
applications of this specification (OPT3). applications of this specification (OPT3).
The handler verifies that the group identifier of the /ace-group/gid o 'control_path', with value the URI path of a resource at the
path is a subset of the 'scope' stored in the access token associated Client, encoded as a CBOR text string. This resource is intended
to this client. If verification fails, the KDC MUST respond with a to be accessible for the KDC to send request messages to the
4.01 (Unauthorized) error message. The KDC MAY set the payload with Client, such as for individual provisioning of new keying material
the 'sign_info' and 'pub_key_enc' parameter, formatted as when performing a group rekeying. In particular, this resource is
'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01 intended for communications concerning exclusively the group or
(Created) response to the Token Post as defined in Section 3.3. Note topic specified in the 'scope' parameter. Note that, in order to
that in this case, the content format MUST be set to application/ support mechanisms of rekeying using this resource, the Client
ace+cbor. needs to be able to act as a CoAP server.
The handler verifies that the group identifier of the /ace-group/
GROUPNAME path is a subset of the 'scope' stored in the access token
associated to this client. If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message. The KDC MAY set
the payload with the 'sign_info' and 'pub_key_enc' parameter,
formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of
the 2.01 (Created) response to the Token Post as defined in
Section 3.3. Note that in this case, the content format MUST be set
to application/ace+cbor.
If the request is not formatted correctly (e.g. unknown, not-expected If the request is not formatted correctly (e.g. unknown, not-expected
fields present, or expected fields with incorrect format), the fields present, or expected fields with incorrect format), the
handler MUST respond with 4.00 (Bad Request) error message. The handler MUST respond with a 4.00 (Bad Request) error message. The
response MAY contain a CBOR map in the payload with ace- response MAY contain a CBOR map in the payload with ace-
groupcomm+cbor format, e.g. it could send back "pub_key_enc" set to groupcomm+cbor format, e.g. it could send back "pub_key_enc" set to
Null if the Client sent its own public key and the KDC is not set to Null if the Client sent its own public key and the KDC is not set to
store public keys of the group members. Application profiles MAY store public keys of the group members. Application profiles MAY
define optional or mandatory payload formats for specific error cases define optional or mandatory payload formats for specific error cases
(OPT6). (OPT6).
If the KDC stores the group members' public keys, the handler If the KDC stores the group members' public keys, the handler
verifies that one public key can be retrieved for the joining node, verifies that one public key can be retrieved for the node, either
either from the 'client_cred' field, or from the KDC previous from the 'client_cred' field, or from the KDC previous knowledge of
knowledge of it. In particular, the KDC checks that such public key it. In particular, the KDC checks that such public key has an
has an accepted format for the group identified by "gid", i.e. it is accepted format for the group identified by "GROUPNAME", i.e. it is
encoded as expected and is compatible with the signature algorithm encoded as expected and is compatible with the signature algorithm
and possible associated parameters. If that cannot be verified, it and possible associated parameters. If that cannot be verified, it
is RECOMMENDED that the handler stops the joining process and is RECOMMENDED that the handler stops the process and responds with a
responds with 4.00 (Bad Request) error message. Applications 4.00 (Bad Request) error message. Applications profiles MAY define
profiles MAY define alternatives (OPT5). alternatives (OPT5).
If the signature contained in "client_cred_verify" does not pass If the signature contained in "client_cred_verify" does not pass
verification, the handler MUST respond with 4.00 (Bad Request) error verification, the handler MUST respond with a 4.00 (Bad Request)
message. error message.
If verification succeeds, the handler adds the retrieved public key If verification succeeds, the handler adds the retrieved public key
of the joining node to the list of public keys stored for the group of the node to the list of public keys stored for the group
identified by "gid". Moreover, the handler assigns a name to the identified by "GROUPNAME". Moreover, the handler assigns a name NAME
node (e.g. "node1"), and creates a sub-resource to /ace-group/gid/ at to the node, and creates a sub-resource to /ace-group/GROUPNAME/ at
the KDC (e.g. "/ace-group/gid/node1"). The handler returns a 2.01 the KDC (e.g. "/ace-group/GROUPNAME/nodes/NODENAME"). The handler
(Created) message containing the symmetric group keying material, the returns a 2.01 (Created) message containing the symmetric group
group policies and all the public keys of the current members of the keying material, the group policies and all the public keys of the
group, if the KDC manages those and the Client requested them. The current members of the group, if the KDC manages those and the Client
response message also contains the URI path to the sub-resource requested them. The response message also contains the URI path to
created for that node in a Location-Path CoAP option. The payload of the sub-resource created for that node in a Location-Path CoAP
the response is formatted as a CBOR map which MAY contain the option. The payload of the response is formatted as a CBOR map which
following fields, which, if included, MUST have the corresponding MAY contain the following fields, which, if included, MUST have the
values: corresponding values:
o 'gkty', identifying the key type of the 'key' parameter. The set o 'gkty', identifying the key type of the 'key' parameter. The set
of values can be found in the "Key Type" column of the "ACE of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry. Implementations MUST verify that the key Groupcomm Key" Registry. Implementations MUST verify that the key
type matches the application profile being used, if present, as type matches the application profile being used, if present, as
registered in the "ACE Groupcomm Key" registry. registered in the "ACE Groupcomm Key" registry.
o 'key', containing the keying material for the group communication, o 'key', containing the keying material for the group communication,
or information required to derive it. or information required to derive it.
skipping to change at page 17, line 13 skipping to change at page 18, line 13
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.5, including its name, type and application profile to in Section 8.5, 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 4: Key Type Values Figure 5: Key Type Values
Optionally, the response MAY contain the following parameters, which, Optionally, the response MAY contain the following parameters, which,
if included, MUST have the corresponding values: if included, MUST have the corresponding values:
o 'ace-groupcomm-profile', with value a CBOR integer that MUST be o 'ace-groupcomm-profile', with value a CBOR integer that MUST be
used to uniquely identify the application profile for group used to uniquely identify the application profile for group
communication. Applications of this specification MUST register communication. Applications of this specification MUST register
an application profile identifier and the related value for this an application profile identifier and the related value for this
parameter in the "ACE Groupcomm Profile" Registry (REQ12). parameter in the "ACE Groupcomm Profile" Registry (REQ12).
o 'exp', with value the expiration time of the keying material for o 'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or the group communication, encoded as a CBOR unsigned integer or
floating-point number. This field contains a numeric value floating-point number. This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds, until the specified UTC date/time, ignoring leap seconds,
analogous to what specified in Section 2 of [RFC7519]. analogous to what specified for NumericDate in Section 2 of
[RFC7519].
o 'pub_keys', may only be present if 'get_pub_keys' was present in o '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 [RFC8152]), which CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which
contains the public keys of all the members of the group. In contains the public keys of all the members of the group. In
particular, each COSE Key in the COSE_KeySet includes the particular, each COSE Key in the COSE_KeySet includes the
identifier of the corresponding group member as value of its 'kid' identifier of the corresponding group member as value of its 'kid'
key parameter. Alternative specific encodings of this parameter key parameter. Alternative specific encodings of this parameter
MAY be defined in applications of this specification (OPT1). The MAY be defined in applications of this specification (OPT1). The
specific format of the identifiers of group members MUST be specific format of the identifiers of group members MUST be
specified in the application profile (REQ9). specified in the application profile (REQ9).
o 'peer_roles', MUST be present if 'pub_keys' is present. This
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
'pub_keys' parameter). The i-th element of the array specifies
the role (or CBOR array of roles) that the group member associated
to the i-th public key in 'pub_keys' has in the group. In
particular, each array element is encoded as the role element of a
scope entry, as defined in Section 3.1.
o 'group_policies', with value a CBOR map, whose entries specify how o 'group_policies', with value a CBOR map, whose entries specify how
the group handles specific management aspects. These include, for the group handles specific management aspects. These include, for
instance, approaches to achieve synchronization of sequence instance, approaches to achieve synchronization of sequence
numbers among group members. The elements of this field are numbers among group members. The elements of this field are
registered in the "ACE Groupcomm Policy" Registry. This registered in the "ACE Groupcomm Policy" Registry. This
specification defines the two elements "Sequence Number specification defines the two elements "Sequence Number
Synchronization Method" and "Key Update Check Interval", which are Synchronization Method" and "Key Update Check Interval", which are
summarized in Figure 5. Application profiles that build on this summarized in Figure 6. Application profiles that build on this
document MUST specify the exact content format of included map document MUST specify the exact content format of included map
entries (REQ14). entries (REQ14).
+-----------------+-------+----------|--------------------|------------+ +--------------+-------+----------|--------------------|------------+
| Name | CBOR | CBOR | Description | Reference | | Name | CBOR | CBOR | Description | Reference |
| | label | type | | | | | label | type | | |
|-----------------+-------+----------|--------------------|------------| |--------------+-------+----------|--------------------|------------|
| Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | | Sequence | TBD1 | tstr/int | Method for a re- | [[this |
| Synchronization | | | cipient node to | document]] | | Number | | | cipient node to | document]] |
| Method | | | synchronize with | | | Synchroniza- | | | synchronize with | |
| | | | 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 Interval | | | in seconds, to | document]] | | Check | | | in seconds, to | document]] |
| | | | check for new | | | Interval | | | check for new | |
| | | | keying material at | | | | | | keying material at | |
| | | | the KDC | | | | | | the KDC | |
+-----------------+-------+----------|--------------------|------------+ +--------------+-------+----------|--------------------|------------+
Figure 5: ACE Groupcomm Policies Figure 6: ACE Groupcomm Policies
o 'mgt_key_material', encoded as a CBOR byte string and containing o '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 19, line 10 skipping to change at page 20, line 19
Specific application profiles that build on this document MUST Specific application profiles that build on this document MUST
specify the communication protocol that members of the group use to specify the communication protocol that members of the group use to
communicate with each other (REQ10) and how exactly the keying communicate with each other (REQ10) and how exactly the keying
material is used to protect the group communication (REQ11). material is used to protect the group communication (REQ11).
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 "gid". group identified by "GROUPNAME".
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client. If verification fails, the KDC MUST
4.01 (Unauthorized) error message. The KDC MAY set the payload with respond with a 4.01 (Unauthorized) error message. The KDC MAY set
the 'sign_info' and 'pub_key_enc' parameter, formatted as the payload with the 'sign_info' and 'pub_key_enc' parameter,
'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01 formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of
(Created) response to the Token Post as defined in Section 3.3. Note the 2.01 (Created) response to the Token Post as defined in
that in this case, the content format MUST be set to application/ Section 3.3. Note that in this case, the content format MUST be set
ace+cbor. to application/ace+cbor.
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 Section 4.1.2.1. 'exp' and 'mgt_key_material' parameters specified in Section 4.1.2.1.
4.1.3. ace-group/gid/pub-key 4.1.3. ace-group/GROUPNAME/pub-key
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 "gid" and returns the public keys of such group identified by "GROUPNAME" and returns the public keys of such group
members. members.
The handler expects a request with payload formatted as a CBOR map. The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MUST contain the The payload of this request is a CBOR Map that MUST contain the
following fields: following fields:
o 'get_pub_keys', whose value is a non-empty CBOR array. Each o 'get_pub_keys', whose value is a non-empty CBOR array. Each
element of the array is the identifier of a group member for the element of the array is the identifier of a group member for the
group identified by "gid". The specific format of public keys as group identified by "GROUPNAME". The specific format of public
well as identifiers of group members MUST be specified by the keys as well as identifiers of group members MUST be specified by
application profile (OPT1, REQ9). the application profile (OPT1, REQ9).
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client. If verification fails, the KDC MUST
4.01 (Unauthorized) error message. 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 the identifier matches with one the current group members for which the identifier matches with one
of those indicated in the request. Then, the handler returns a 2.05 of those indicated in the request. Then, the handler returns a 2.05
(Content) message response with payload formatted as a CBOR map (Content) message response with payload formatted as a CBOR map,
containing only the 'pub_keys' parameter from Section 4.1.2.1, which containing only the 'pub_keys' and 'peer_roles' parameters from
encodes the list of public keys of those group members including the Section 4.1.2.1. In particular, 'pub_keys' encodes the list of
respective member identifiers. If the KDC does not store any public public keys of those group members including the respective member
key associated with the specified member identifiers, the handler identifiers, while 'peer_roles' encodes their respective role (or
returns a response with payload formatted as a CBOR byte string of CBOR array of roles) in the group.
zero length. The specific format of public keys as well as of
identifiers of group members is specified by the application profile If the KDC does not store any public key associated with the
(OPT1, REQ9). specified member identifiers, 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).
The handler MAY enforce one of the following policies, in order to The handler MAY enforce one of the following policies, in order to
handle possible identifiers that are included in the 'get_pub_keys' handle possible identifiers that are included in the 'get_pub_keys'
parameter of the request but are not associated to any current group parameter of the request but are not associated to any current group
member. Such a policy MUST be specified by the application profile member. Such a policy MUST be specified by the application profile
(REQ13) (REQ13)
o The KDC silently ignores those identifiers. o The KDC silently ignores those identifiers.
o The KDC retains public keys of group members for a given amount of o 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.
4.1.3.2. GET Handler 4.1.3.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client. If verification fails, the KDC MUST
4.01 (Unauthorized) error message. respond with a 4.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the public keys of all the current group members, message containing the public keys of all the current group members,
for the group identified by "gid". The payload of the response is for the group identified by "GROUPNAME". The payload of the response
formatted as a CBOR map containing only the 'pub_keys' parameter from is formatted as a CBOR map, containing only the 'pub_keys' and
Section 4.1.2.1, which encodes the list of public keys of all the 'peer_roles' parameters from Section 4.1.2.1. In particular,
group members including the respective member identifiers. If the 'pub_keys' encodes the list of public keys of those group members
KDC does not store any public key for the group, the handler returns including the respective member identifiers, while 'peer_roles'
a response with payload formatted as a CBOR byte string of zero encodes their respective role (or CBOR array of roles) in the group.
length. The specific format of public keys as well as of identifiers
of group members is specified by the application profile (OPT1,
REQ9).
4.1.4. ace-group/gid/policies 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).
4.1.4. ace-group/GROUPNAME/policies
This resource implements a GET handler. This resource implements a GET handler.
4.1.4.1. GET Handler 4.1.4.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client. If verification fails, the KDC MUST
4.01 (Unauthorized) error message. respond with a 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
"gid". 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/gid/ctx-num 4.1.5. ace-group/GROUPNAME/ctx-num
This resource implements a GET handler. This resource implements a GET handler.
4.1.5.1. GET Handler 4.1.5.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client. If verification fails, the KDC MUST
4.01 (Unauthorized) error message. respond with a 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. The payload of the response is formatted as a CBOR material. The payload of the response is formatted as a CBOR
integer. integer.
4.1.6. ace-group/gid/node 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 "node") for the group identified by "gid". (identified by "NODENAME") for the group identified by "GROUPNAME".
The handler expects a request with empty payload. The handler expects a request with empty payload.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client, identified by "NODENAME". If verification
4.01 (Unauthorized) error message. fails, the KDC MUST respond with a 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 individual keying material for the message containing newly-generated individual keying material for the
Client, or information enabling the Client to derive it. The payload Client, or information enabling the Client to derive it. The payload
of the response is formatted as a CBOR map. The specific format of of the response is formatted as a CBOR map. The specific format of
newly-generated individual keying material for group members, or of newly-generated individual keying material for group members, or of
the information to derive it, and corresponding CBOR label, MUST be the information to derive it, and corresponding CBOR label, MUST be
specified in the application profile (REQ15) and registered in specified in the application profile (REQ15) and registered in
Section 8.4. Section 8.4.
4.1.6.2. GET Handler 4.1.6.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client, identified by "node". If verification fails, the KDC associated to this client, identified by "NODENAME". If verification
MUST respond with a 4.01 (Unauthorized) error message. fails, the KDC MUST respond with a 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.4. application profile (REQ15) and registered in Section 8.4.
4.1.6.3. DELETE Handler 4.1.6.3. DELETE Handler
The DELETE handler removes the node (identified by "node") from the The DELETE handler removes the node identified by "NODENAME" from the
group, for the group identified by "gid". If the node sending the group identified by "GROUPNAME". If the node sending the request and
request and the node name used in the Uri-Path do not match, the the node name used in the Uri-Path do not match, the handler responds
handler responds with a 4.01 (Unauthorized) error response. with a 4.01 (Unauthorized) error response.
TODO: Check the previous sentence.
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 MAY contain only the The payload of this request is a CBOR Map that MAY contain only the
'scope' field as specified in Section 4.1.2.1. 'scope' field as specified in Section 4.1.2.1.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/
path is a subset of the 'scope' stored in the access token associated GROUPNAME path is a subset of the 'scope' stored in the access token
to this client. If verification fails, the KDC MUST respond with a associated to this client, identified by "NODENAME". If verification
4.01 (Unauthorized) error message. fails, the KDC MUST respond with a 4.01 (Unauthorized) error message.
If the request contained a 'scope' field, the handler MUST extract If the request contained a 'scope' field, the handler MUST extract
the roles for that client. If the value is such that the KDC cannot the roles for that client. If the value is such that the KDC cannot
extract all the necessary information to understand and process it extract all the necessary information to understand and process it
correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00 correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00
(Bad Request) error message. (Bad Request) 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 "gid", for specific roles if roles were specified group identified by "GROUPNAME", for specific roles if roles were
in the 'scope' field, or for all roles. That includes removing the specified in the 'scope' field, or for all roles. That includes
public key of the client if the KDC keep tracks of that. Then, the removing the public key of the client if the KDC keep tracks of that.
handler delete the sub-resource /node and returns a 2.02 (Deleted) Then, the handler delete the sub-resource nodes/NODENAME and returns
message with empty payload. a 2.02 (Deleted) message with empty payload.
4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key
This resource implements a POST handler.
4.1.7.1. POST Handler
The POST handler is used to replace the stored public key of this
client (identified by "NODENAME") with the one specified in the
request at the KDC, for the group identified by "GROUPNAME".
The handler expects a POST request with payload as specified in
Section 4.1.2.1, with the difference that it includes only the
parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In
particular, the signature included in 'client_cred_verify' is
expected to be computed as defined in Section 4.1.2.1. Since no
nonce N_S is provided by the KDC, it is REQUIRED of the specific
profile to define how the nonce N_S is generated (REQ17). The
specific format of public keys is specified by the application
profile (OPT1).
The handler verifies that the group identifier GROUPNAME is a subset
of the 'scope' stored in the access token associated to this client.
If verification fails, the KDC MUST respond with a 4.01
(Unauthorized) error message.
If the request is not formatted correctly (e.g. unknown, not-expected
fields present, or expected fields with incorrect format), the
handler MUST respond with a 4.00 (Bad Request) error message.
Application profiles MAY define optional or mandatory payload formats
for specific error cases (OPT6).
Otherwise, the handler checks that the public key specified in the
'client_cred' field has a valid format for the group identified by
"GROUPNAME", i.e. it is encoded as expected and is compatible with
the signature algorithm and possible associated parameters. If that
cannot be verified, the handler MUST respond with a 4.00 (Bad
Request) error message. Applications profiles MAY define
alternatives (OPT5).
Otherwise, the handler verifies the signature contained in the
'client_cred_verify' field of the request, using the public key
specified in the 'client_cred' field. If the signature does not pass
verification, the handler MUST respond with a 4.00 (Bad Request)
error message.
If verification succeeds, the handler replaces the old public key of
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
node NODENAME, in the list of group members' public keys for the
group identified by GROUPNAME. Then, the handler replies with a 2.04
(Changed) response, which does not include a payload.
4.2. Joining Exchange 4.2. Joining Exchange
Figure 6 gives an overview of the Joining exchange between Client and Figure 7 gives an overview of the Joining exchange between Client and
KDC, when the Client first joins a group. KDC, when the Client first joins a group.
Client KDC Client KDC
| | | |
|-------- Joining Request: POST /ace-group/gid --------->| |----- Joining Request: POST /ace-group/GROUPNAME ------>|
| | | |
|<--------- Joining Response: 2.01 (Created) ----------- | |<--------- Joining Response: 2.01 (Created) ----------- |
| Location-Path = "/ace-group/gid/node" | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
Figure 6: Message Flow of First Exchange for Group Joining Figure 7: Message Flow of First Exchange for Group Joining
If not previously established, the Client and the KDC MUST first If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel (REQ16). This can establish a pairwise secure communication channel (REQ16). This can
be achieved, for instance, by using a transport profile of ACE. The be achieved, for instance, by using a transport profile of ACE. The
Joining exchange MUST occur over that secure channel. The Client and Joining exchange MUST occur over that secure channel. The Client and
the KDC MAY use that same secure channel to protect further pairwise the KDC MAY use that same secure channel to protect further pairwise
communications that must be secured. communications that must be secured.
The secure communication protocol is REQUIRED to establish the secure The secure communication protocol is REQUIRED to establish the secure
channel by using the proof-of-possession key bound to the access channel by using the proof-of-possession key bound to the access
token. As a result, the proof-of-possession to bind the access token token. As a result, the proof-of-possession to bind the access token
to the Client is performed by using the proof-of-possession key bound to the Client is performed by using the proof-of-possession key bound
to the access token for establishing secure communication between the to the access token for establishing secure communication between the
Client and the KDC. Client and the KDC.
To join the group, the Client sends a CoAP POST request to the /ace- To join the group, the Client sends a CoAP POST request to the /ace-
group/gid endpoint at the KDC, where gid is the group identifier of group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group
the group to join, formatted as specified in Section 4.1.2.1. This identifier of the group to join, formatted as specified in
group identifier is the same as the 'scope' value of the Section 4.1.2.1. This group identifier is the same as the scope
Authorization Request/Response, or it can be retrieved from it. Note entry corresponding to that group, specified in the 'scope' parameter
that, in case of successful joining, the Client will receive the URI of the Authorization Request/Response, or it can be retrieved from
to retrieve individual or group keying material and to leave the it. Note that, in case of successful joining, the Client will
group in the Location-Path option of the response. receive the URI to retrieve individual or group keying material and
to leave the group in the Location-Path option of the 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 new node's joining the group. To this current group members, upon a new node's joining the group. To this
end, the KDC uses the message format of the Joining Response (see end, the KDC uses the message format of the Joining Response (see
Section 4.1.2.1). Application profiles may define alternative ways Section 4.1.2.1). Application profiles may define alternative ways
of retrieving the keying material, such as sending separate requests of retrieving the keying material, such as sending separate requests
to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2,
Section 4.1.4.1). After distributing the new group keying material, Section 4.1.4.1). After distributing the new group keying material,
the KDC MUST increment the version number of the keying material. the KDC MUST increment the version number of the keying material.
4.3. Retrieval of Updated Keying Material 4.3. Retrieval of Updated Keying Material
A node stops using the group keying material upon its expiration, When any of the following happens, a node MUST stop using the owned
according to what indicated by the KDC with the 'exp' parameter in a group keying material to protect outgoing messages, and SHOULD stop
Joining response, or to a pre-configured value. Then, if it wants to using it to decrypt and verify incoming messages.
continue participating in the group communication, the node has to
request new updated keying material from the KDC.
The Client may need to request the latest group keying material also o Upon expiration of the keying material, according to what
upon receiving messages from other group members without being able indicated by the KDC with the 'exp' parameter in a Joining
to retrieve the material to correctly decrypt them. This may be due Response, or to a pre-configured value.
to a previous update of the group keying material (rekeying)
triggered by the KDC, that the Client was not able to receive or
decrypt. To this end, the Client sends a CoAP GET request to the
/ace-group/gid/node endpoint at the KDC, formatted as specified in
Section 4.1.6.2.
Note that policies can be set up so that the Client sends a Key Re- o Upon receiving a notification of revoked/renewed keying material
Distribution Request to the KDC only after a given number of from the KDC, possibly as part of an update of the keying material
unsuccessfully decrypted incoming messages. It is application (rekeying) triggered by the KDC.
dependent and pertaining to the particular message exchange (e.g.
[I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct o Upon receiving messages from other group members without being
clients to retain unsuccessfully decrypted messages and for how long, able to retrieve the keying material to correctly decrypt them.
so that they can be decrypted after getting updated keying material, This may be due to rekeying messages previously sent by the KDC,
rather than just considered non valid messages to discard right away that the Client was not able to receive or decrypt.
(OPT4).
In either case, if it wants to continue participating in the group
communication, the node has to request the latest keying material
from the KDC. To this end, the Client sends a CoAP GET request to
the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC,
formatted as specified in Section 4.1.6.2.
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
messages could not be decrypted (because of failed decryption
processing or inability to retrieve the necessary keying material).
It is application dependent and pertaining to the particular message
exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these
policies, to instruct clients to retain incoming messages and for how
long (OPT4). This allows clients to possibly decrypt such messages
after getting updated keying material, rather than just 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 7 gives an overview of the exchange described above. Figure 8 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|--- Key Distribution Request: GET ace-group/gid/node -->| |------------------ Key Distribution Request: --------------->|
| | | GET ace-group/GROUPNAME/nodes/NODENAME |
|<----- Key Distribution Response: 2.05 (Content) -------| | |
| | |<-------- Key Distribution Response: 2.05 (Content) ---------|
| |
Figure 7: Message Flow of Key Distribution Request-Response Figure 8: Message Flow of Key Distribution Request-Response
Alternatively, the re-distribution of keying material can be Alternatively, the re-distribution of keying material can be
initiated by the KDC, which e.g.: initiated by the KDC, which e.g.:
o Can make the ace-group/gid/node resource Observable, and send o Can make the ace-group/GROUPNAME/nodes/NODENAME resource
notifications to Clients when the keying material is updated. Observable, and send notifications to Clients when the keying
material is updated.
o Can send the Key Distribution Response as one or multiple o Can send the payload of the Key Distribution Response in one or
multicast requests to the members of the group, using secure multiple multicast POST requests to the members of the group,
rekeying schemes such as [RFC2093][RFC2094][RFC2627]. using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627].
o Can send unicast requests to each Client over a secure channel, o Can send unicast POST requests to each Client over a secure
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
possibly provided by the intended recipient upon joining the
group, as specified in the 'control_path' parameter of the Joining
Request (see Section 4.1.2.1).
o Can act as a publisher in a pub-sub scenario, and update the o Can act as a publisher in a pub-sub scenario, and update the
keying material by publishing on a specific topic on a broker, keying material by publishing on a specific topic on a broker,
which all the members of the group are subscribed to. which all the members of the group are subscribed to.
Note that these methods of KDC-initiated key distribution have Note that these methods of KDC-initiated key distribution have
different security properties and require different security different security properties and require different security
associations. associations.
4.4. Retrieval of New Keying Material 4.4. Retrieval of New Keying Material
Beside possible expiration and depending on what part of the keying Beside possible expiration and depending on what part of the keying
material is no longer eligible to be used, the client may need to material is no longer eligible to be used, the client may need to
communicate to the KDC its need for that part to be renewed. For communicate to the KDC its need for that part to be renewed. For
example, if the Client uses an individual key to protect outgoing example, if the Client uses an individual key to protect outgoing
traffic and has to renew it, the node may request a new one, or new traffic and has to renew it, the node may request a new one, or new
input material to derive it, without renewing the whole group keying input material to derive it, without renewing the whole group keying
material. To this end, the client performs a Key Renewal Request/ material.
Response exchange with the KDC, that is a CoAP PUT request to the
/ace-group/gid/node endpoint at the KDC, where gid is the group
identifier and node the node's name, and formatted as defined in
Section 4.1.6.2.
Figure 8 gives an overview of the exchange described above. 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-
group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME
is the group identifier and NODENAME is the node's name, and
formatted as defined in Section 4.1.6.2.
Client KDC Figure 9 gives an overview of the exchange described above.
| |
|---- Key Renewal Request: PUT ace-group/gid/node --->|
| |
|<----- Key Renewal Response: 2.05 (Content) ---------|
| |
Figure 8: Message Flow of Key Renewal Request-Response Client KDC
| |
|------------------ Key Renewal Request: -------------->|
| PUT ace-group/GROUPNAME/nodes/NODENAME |
| |
|<-------- Key Renewal Response: 2.05 (Content) --------|
| |
Figure 9: Message Flow of Key Renewal Request-Response
Note the difference between the Key Distribution Request and the Key Note the difference between the Key Distribution Request and the Key
Renewal Request: while the first one only triggers distribution (the Renewal Request: while the first one only triggers distribution (the
renewal might have happened independently, e.g. because of renewal might have happened independently, e.g. because of
expiration), the second one triggers the KDC to produce new expiration), the second one triggers the KDC to produce new
individual keying material for the requesting node. individual keying material for the requesting node.
4.5. Retrieval of Public Keys for Group Members Furthermore, policies can be set up so that, upon receiving a Key
Renewal Request, the KDC replies to the client with an error
response, and then performs a complete group rekeying (OPT8).
4.5. Retrieval of Public Keys and Roles for Group Members
In case the KDC maintains the public keys of group members, a node in In case the KDC maintains the public keys of group members, a node in
the group can contact the KDC to request public keys of either all the group can contact the KDC to request public keys and roles of
group members or a specified subset, by sending a CoAP GET or FETCH either all group members or a specified subset, by sending a CoAP GET
request to the /ace-group/gid/pub-key endpoint at the KDC, where gid or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the
is the group identifier, and formatted as defined in Section 4.1.3.2 KDC, where GROUPNAME is the group identifier, and formatted as
and Section 4.1.3.1. defined in Section 4.1.3.2 and Section 4.1.3.1.
Figure 9 and Figure 10 give an overview of the exchanges described When receiving a Public Key Response, the requesting group member
stores (or updates) the public keys (in the 'pub_keys' parameter) and
roles (in the 'peer_roles' parameter) of the group members.
Figure 10 and Figure 11 give an overview of the exchanges described
above. above.
Client KDC Client KDC
| | | |
|---- Public Key Request: GET /ace-group/gid/pub-key --->| |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->|
| | | |
|<--------- Public Key Response: 2.05 (Content) ---------| |<--------- Public Key Response: 2.05 (Content) ---------|
| | | |
Figure 9: Message Flow of Public Key Exchange to Request All Members Figure 10: Message Flow of Public Key Exchange to Request All Members
Public Keys Public Keys
Client KDC Client KDC
| | | |
|--- Public Key Request: FETCH /ace-group/gid/pub-key --->| |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->|
| | | |
|<--------- Public Key Response: 2.01 (Created) ---------| |<--------- Public Key Response: 2.01 (Created) ----------|
| | | |
Figure 10: Message Flow of Public Key Exchange to Request Specific Figure 11: Message Flow of Public Key Exchange to Request Specific
Members Public Keys Members Public Keys
4.6. Retrieval of Group Policies 4.6. Update of Public Key
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, and replace the currently stored one.
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-
group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where
GROUPNAME is the group identifier and NODENAME is the node's name.
The request is formatted as specified in Section 4.1.7.1.
Figure Figure 12 gives an overview of the exchange described above.
Client KDC
| |
|-------------- Public Key Update Request: ---------------------->|
| POST ace-group/GROUPNAME/nodes/NODENAME/pub-key |
| |
|<------- Public Key Update Response: 2.04 (Changed) -------------|
| |
Figure 12: Message Flow of Public Key Update Request-Response
4.7. Retrieval of Group Policies
A node in the group can contact the KDC to retrieve the current group A node in the group can contact the KDC to retrieve the current group
policies, by sending a CoAP GET request to the /ace-group/gid/ policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/
policies endpoint at the KDC, where gid is the group identifier, and policies endpoint at the KDC, where GROUPNAME is the group
formatted as defined in Section 4.1.4.1 identifier, and formatted as defined in Section 4.1.4.1
Figure 11 gives an overview of the exchange described above. Figure 13 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|--- Policies Request: GET ace-group/gid/policies ---->| |-Policies Request: GET ace-group/GROUPNAME/policies ->|
| | | |
|<--------- Policies Response: 2.05 (Content) ---------| |<--------- Policies Response: 2.05 (Content) ---------|
| | | |
Figure 11: Message Flow of Policies Request-Response Figure 13: Message Flow of Policies Request-Response
4.7. Retrieval of Keying Material Version 4.8. Retrieval of Keying Material Version
A node in the group can contact the KDC to request information about A node in the group can contact the KDC to request information about
the version number of the symmetric group keying material, by sending the version number of the symmetric group keying material, by sending
a CoAP GET request to the /ace-group/gid/ctx-num endpoint at the KDC, a CoAP GET request to the /ace-group/GROUPNAME/ctx-num endpoint at
where gid is the group identifier, formatted as defined in the KDC, where GROUPNAME is the group identifier, formatted as
Section 4.1.5.1. In particular, the version is incremented by the defined in Section 4.1.5.1. In particular, the version is
KDC every time the group keying material is renewed. incremented by the KDC every time the group keying material is
renewed.
Figure 12 gives an overview of the exchange described above. Figure 14 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|----- Version Request: GET ace-group/gid/ctx-num ----->| |-- Version Request: GET ace-group/GROUPNAME/ctx-num -->|
| | | |
|<--------- Version Response: 2.05 (Content) -----------| |<--------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 12: Message Flow of Version Request-Response Figure 14: Message Flow of Version Request-Response
4.8. Group Leaving Request 4.9. Group Leaving Request
A node can actively request to leave the group. In this case, the A node can actively request to leave the group. In this case, the
Client sends a CoAP DELETE request to the endpoint /ace-group/gid/ Client sends a CoAP DELETE request to the endpoint /ace-
node at the KDC, where gid is the group identifier and node the group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the
node's name, formatted as defined in Section 4.1.6.3 group identifier and NODENAME is the node's name, formatted as
defined in 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
skipping to change at page 28, line 48 skipping to change at page 32, line 31
again. Then, as long as the node is still authorized to join the again. Then, as long as the node is still authorized to join the
group, i.e. it still has a valid access token, it can re-request to group, i.e. it still has a valid access token, it can re-request to
join the group directly to the KDC without needing to retrieve a new join the group directly to the KDC without needing to retrieve a new
access token from the AS. This means that the KDC might decide to access token from the AS. This means that the KDC might decide to
keep track of nodes with valid access tokens, before deleting all keep track of nodes with valid access tokens, before deleting all
information about the leaving node. information about the leaving node.
A node may be evicted from the group in the following cases. A node may be evicted from the group in the following cases.
1. The node explicitly asks to leave the group, as defined in 1. The node explicitly asks to leave the group, as defined in
Section 4.8. Section 4.9.
2. The node has been found compromised or is suspected so. 2. The node has been found compromised or is suspected so.
3. The node's authorization to be a group member is expired. If the 3. The node's authorization to be a group member is expired. If the
AS provides Token introspection (see Section 5.7 of AS provides Token introspection (see Section 5.7 of
[I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check
whether: whether:
* the node is not authorized anymore; * the node is not authorized anymore;
* the access token is still valid, upon its expiration. * the access token is still valid, upon its expiration.
Either case, once aware that a node is not authorized anymore, In either case, once aware that a node is not authorized anymore, the
the KDC has to remove the unauthorized node from the list of KDC has to remove the unauthorized node from the list of group
group members, if the KDC keeps track of that. members, if the KDC keeps track of that.
In case of forced eviction, the KDC MAY explicitly inform the leaving
node, if the Client implements the 'control_path' resource specified
in Section 4.1.2.1. To this end, the KDC can send a DEL request,
targeting the URI specified in the 'control_path' parameter of the
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 | array | Section | | scope | TBD | byte string | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | | |
| | | | | | get_pub_keys | TBD | array | Section 4.1.2.1, |
| get_pub_keys | TBD | array | Section | | | | | Section 4.1.3.1 |
| | | | 4.1.2.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 | | client_cred_verify | TBD | byte string | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | | |
| | | | | | pub_keys_repos | TBD | text string | Section 4.1.2.1 |
| client_cred_verify | TBD | byte string | Section | | | | | |
| | | | 4.1.2.1 | | control_path | TBD | text string | Section 4.1.2.1 |
| | | | | | | | | |
| pub_keys_repos | TBD | array | Section | | gkty | TBD | int / text | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | string | |
| | | | | | | | | |
| gkty | TBD | int / byte string | Section | | key | TBD | see "ACE | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | Groupcomm Key" | |
| | | | | | | | Registry | |
| key | TBD | see "ACE Groupcomm | Section | | | | | |
| | | Key" Registry | 4.1.2.1 | | num | TBD | int | Section 4.1.2.1 |
| | | | | | | | | |
| num | TBD | int | Section | | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | | |
| | | | | | exp | TBD | int / float | Section 4.1.2.1 |
| ace-groupcomm-profile | TBD | int | Section | | | | | |
| | | | 4.1.2.1 | | pub_keys | TBD | byte string | Section 4.1.2.1 |
| | | | | | | | | |
| exp | TBD | int / float | Section | | peer_roles | TBD | array | Section 4.1.2.1 |
| | | | 4.1.2.1 | | | | | |
| | | | | | group_policies | TBD | map | Section 4.1.2.1 |
| pub_keys | TBD | byte string | Section | | | | | |
| | | | 4.1.2.1 | | mgt_key_material | TBD | byte string | 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 |
| | | | |
| get_pub_keys | TBD | array | Section |
| | | | 4.1.3.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]. Appendix B.2 of [RFC8613].
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
skipping to change at page 35, line 7 skipping to change at page 39, line 24
provided in Section 8.9. provided in Section 8.9.
The columns of this Registry are: The columns of this Registry are:
o Name: This is a descriptive name that enables easier reference to o Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o Key Type Value: This is the value used to identify the keying o Key Type Value: This is the value used to identify the keying
material. These values MUST be unique. The value can be a material. These values MUST be unique. The value can be a
positive integer, a negative integer, or a string. positive integer, a negative integer, or a text string.
o Profile: This field may contain one or more descriptive strings of o Profile: This field may contain one or more descriptive strings of
application profiles to be used with this item. The values should application profiles to be used with this item. The values should
be taken from the Name column of the "ACE Groupcomm Profile" be taken from the Name column of the "ACE Groupcomm Profile"
Registry. Registry.
o Description: This field contains a brief description of the keying o Description: This field contains a brief description of the keying
material. material.
o References: This contains a pointer to the public specification o 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 4. This Registry has been initially populated by the values in Figure 5.
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.6. ACE Groupcomm Profile Registry 8.6. 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.9. It should be noted that, in addition to are provided in Section 8.9. It should be noted that, in addition to
the expert review, some portions of the Registry require a the expert review, some portions of the Registry require a
skipping to change at page 36, line 39 skipping to change at page 41, line 9
o CBOR type: the CBOR type used to encode the value of this group o CBOR type: the CBOR type used to encode the value of this group
communication policy. communication policy.
o Description: This field contains a brief description for this o Description: This field contains a brief description for this
group communication policy. group communication policy.
o Reference: This field contains a pointer to the public o 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 5. This registry will be initially populated by the values in Figure 6.
8.8. Sequence Number Synchronization Method Registry 8.8. 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.9. It should be noted review guidelines are provided in Section 8.9. 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 38, line 19 skipping to change at page 42, line 38
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 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)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), December 2019. (work in progress), February 2020.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-11 (work in progress), January 2020. params-12 (work in progress), February 2020.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-06 (work in progress), draft-ietf-core-oscore-groupcomm-07 (work in progress),
November 2019. March 2020.
[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>.
[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>.
skipping to change at page 39, line 18 skipping to change at page 43, line 37
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.dijk-core-groupcomm-bis] [I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-02 (work in progress), November dijk-core-groupcomm-bis-03 (work in progress), March
2019. 2020.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-09 (work in progress), December 2019. authorize-09 (work in progress), December 2019.
[I-D.ietf-ace-mqtt-tls-profile] [I-D.ietf-ace-mqtt-tls-profile]
Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in of ACE", draft-ietf-ace-mqtt-tls-profile-04 (work in
progress), December 2019. progress), March 2020.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-08 (work in progress), July 2019. oscore-profile-10 (work in progress), March 2020.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-09 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), September 2019. progress), September 2019.
[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,
skipping to change at page 40, line 19 skipping to change at page 44, line 36
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999, DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>. <https://www.rfc-editor.org/info/rfc2627>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
skipping to change at page 41, line 11 skipping to change at page 45, line 22
[1] mailto:iesg@ietf.org [1] mailto:iesg@ietf.org
[2] mailto:francesca.palombini@ericsson.com [2] mailto:francesca.palombini@ericsson.com
Appendix A. Requirements on Application Profiles Appendix A. Requirements on Application Profiles
This section lists the requirements on application profiles of this This section lists the requirements on application profiles of this
specification,for the convenience of application profile designers. specification,for the convenience of application profile designers.
o REQ1: Specify the encoding and value of the identifier of group or o REQ1: Specify the encoding and value of the identifier of group or
topic of 'scope' (see Section 3.1). topic, for scope entries of 'scope' (see Section 3.1).
o REQ2: Specify the encoding and value of roles of 'scope' (see o REQ2: Specify the encoding and value of roles, for scope entries
Section 3.1). of 'scope' (see Section 3.1).
o REQ3: If used, specify the acceptable values for 'sign_alg' (see o REQ3: If used, specify the acceptable values for 'sign_alg' (see
Section 3.3). Section 3.3).
o REQ4: If used, specify the acceptable values for 'sign_parameters' o REQ4: If used, specify the acceptable values for 'sign_parameters'
(see Section 3.3). (see Section 3.3).
o REQ5: If used, specify the acceptable values for o REQ5: If used, specify the acceptable values for
'sign_key_parameters' (see Section 3.3). 'sign_key_parameters' (see Section 3.3).
skipping to change at page 42, line 40 skipping to change at page 47, line 6
Section 4.1.2.1). Section 4.1.2.1).
o OPT2: Optionally, specify the negotiation of parameter values for o OPT2: Optionally, specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' and signature algorithm and signature keys, if 'sign_info' and
'pub_key_enc' are not used (see Section 3.3). 'pub_key_enc' are not used (see Section 3.3).
o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the
default is not used (see Section 4.1.2.1). default is not used (see Section 4.1.2.1).
o OPT4: Optionally, specify policies that instruct clients to retain o OPT4: Optionally, specify policies that instruct clients to retain
unsuccessfully decrypted messages and for how long, so that they messages and for how long, if they are unsuccessfully decrypted
can be decrypted after getting updated keying material. (see Section 4.3). This makes it possible to decrypt such
messages after getting updated keying material.
o OPT5: Optionally, specify the behavior of the handler in case of o OPT5: Optionally, specify the behavior of the handler in case of
failure to retrieve a public key for the specific node (see failure to retrieve a public key for the specific node (see
Section 4.1.2.1). Section 4.1.2.1).
o OPT6: Optionally, specify possible or required payload formats for o OPT6: Optionally, specify possible or required payload formats for
specific error cases. specific error cases.
o OPT7: Optionally, specify CBOR values to use for abbreviating
identifiers of roles in the group or topic (see Section 3.1).
o OPT8: Optionally, specify policies for the KDC to perform group
rekeying after receiving a Key Renewal Request (see Section 4.4).
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -03 to -04 B.1. Version -04 to -05
o Updated uppercase/lowercase URI segments for KDC resources.
o Supporting single Access Token for multiple groups/topics.
o Added 'control_path' parameter in the Joining Request.
o Added 'peer_roles' parameter to support legal requesters/
responders.
o Clarification on stopping using owned keying material.
o Clarification on different reasons for processing failures,
related policies, and requirement OPT4.
o Added a KDC sub-resource for group members to upload a new public
key.
o Possible group rekeying following an individual Key Renewal
Request.
o Clarified meaning of requirement REQ3; added requirement OPT8.
o Editorial improvements.
B.2. Version -03 to -04
o Revised RESTful interface, as to methods and parameters. o Revised RESTful interface, as to methods and parameters.
o Extended processing of joining request, as to check/retrieval of o Extended processing of joining request, as to check/retrieval of
public keys. public keys.
o Revised and extended profile requirements. o Revised and extended profile requirements.
o Clarified specific usage of parameters related to signature o Clarified specific usage of parameters related to signature
algorithms/keys. algorithms/keys.
o Included general content previously in draft-ietf-ace-key- o Included general content previously in draft-ietf-ace-key-
groupcomm-oscore groupcomm-oscore
o Registration of media type and content format application/ace- o Registration of media type and content format application/ace-
group+cbor group+cbor
o Editorial improvements. o Editorial improvements.
B.2. Version -02 to -03 B.3. Version -02 to -03
o Exchange of information on the countersignature algorithm and o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 3.3). related parameters, during the Token POST (Section 3.3).
o Restructured KDC interface, with new possible operations o Restructured KDC interface, with new possible operations
(Section 4). (Section 4).
o Client PoP signature for the Joining Request upon joining o Client PoP signature for the Joining Request upon joining
(Section 4.1.2.1). (Section 4.1.2.1).
o Revised text on group member removal (Section 5). o Revised text on group member removal (Section 5).
o Added more profile requirements (Appendix A). o Added more profile requirements (Appendix A).
B.3. Version -01 to -02 B.4. Version -01 to -02
o Editorial fixes. o Editorial fixes.
o Distinction between transport profile and application profile o Distinction between transport profile and application profile
(Section 1.1). (Section 1.1).
o New parameters 'sign_info' and 'pub_key_enc' to negotiate o New parameters 'sign_info' and 'pub_key_enc' to negotiate
parameter values for signature algorithm and signature keys parameter values for signature algorithm and signature keys
(Section 3.3). (Section 3.3).
skipping to change at page 44, line 41 skipping to change at page 49, line 34
o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4),
populated with the values in Section 9. populated with the values in Section 9.
o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated
with two entries "Sequence Number Synchronization Method" and "Key with two entries "Sequence Number Synchronization Method" and "Key
Update Check Interval" (Section 4.2). Update Check Interval" (Section 4.2).
o Improved list of requirements for application profiles o Improved list of requirements for application profiles
(Appendix A). (Appendix A).
B.4. Version -00 to -01 B.5. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
o Defined error handling on the KDC (Sections 4.2 and 6.2). o Defined error handling on the KDC (Sections 4.2 and 6.2).
o Updated format of the Key Distribution Response as a whole o Updated format of the Key Distribution Response as a whole
(Section 4.2). (Section 4.2).
o Generalized format of 'pub_keys' in the Key Distribution Response o Generalized format of 'pub_keys' in the Key Distribution Response
 End of changes. 121 change blocks. 
433 lines changed or deleted 623 lines changed or added

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