draft-ietf-ace-key-groupcomm-02.txt   draft-ietf-ace-key-groupcomm-03.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: January 6, 2020 RISE AB Expires: May 7, 2020 RISE AB
July 05, 2019 November 04, 2019
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-02 draft-ietf-ace-key-groupcomm-03
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 January 6, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . 6
3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8
4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 11 4. Keying Material Provisioning and Group Membership Management 11
4.1. Key Distribution Request . . . . . . . . . . . . . . . . 12 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 12
4.2. Key Distribution Response . . . . . . . . . . . . . . . . 13 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 21
5. Removal of a Node from the Group . . . . . . . . . . . . . . 16 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 22
5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 16 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 24
5.2. Request to Leave the Group . . . . . . . . . . . . . . . 16 4.5. Retrieval of Public Keys for Group Members . . . . . . . 24
6. Retrieval of New or Updated Keying Material . . . . . . . . . 17 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 25
6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 18 4.7. Retrieval of Keying Material Version . . . . . . . . . . 25
6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 19 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 26
7. Retrieval of Public Keys for Group Members . . . . . . . . . 19 5. Removal of a Node from the Group . . . . . . . . . . . . . . 26
7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 20 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 27
7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 21 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 29
9. ACE Groupcomm Request Type . . . . . . . . . . . . . . . . . 22 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10.1. Update of Keying Material . . . . . . . . . . . . . . . 24 8.1. ACE Authorization Server Request Creation Hints Registry 30
10.2. Block-Wise Considerations . . . . . . . . . . . . . . . 24 8.2. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.3. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 31
11.1. ACE Authorization Server Request Creation Hints Registry 25 8.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 32
11.2. ACE Public Key Encoding Registry . . . . . . . . . . . . 25 8.5. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 32
11.3. ACE Groupcomm Parameters Registry . . . . . . . . . . . 26 8.6. Sequence Number Synchronization Method Registry . . . . . 33
11.4. Ace Groupcomm Request Type Registry . . . . . . . . . . 26 8.7. Expert Review Instructions . . . . . . . . . . . . . . . 34
11.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . 35
11.8. Sequence Number Synchronization Method Registry . . . . 29 Appendix A. Requirements on Application Profiles . . . . . . . . 37
11.9. Expert Review Instructions . . . . . . . . . . . . . . . 29 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 31 B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 40
Appendix A. Requirements on Application Profiles . . . . . . . . 33 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 34
B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 format of messages 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 [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing-
subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based
on CBOR [RFC7049], so CBOR is the format used in this specification. on CBOR [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 to Profiles that use group communication can build on this document, by
specify the selection of the message parameters defined in this defining a number of details such as the exact group communication
document to use and their values. Known applications that can protocol and security protocols used. The specific list of details a
benefit from this document would be, for example, those addressing profile needs to define is in Appendix A.
group communication based on multicast
[RFC7390][I-D.dijk-core-groupcomm-bis] or publishing/subscribing
[I-D.ietf-core-coap-pubsub] in ACE.
If the application requires backward and forward security, updated If the application requires backward and forward security, updated
keying material is generated and distributed to the group members keying material is generated and distributed to the group members
(rekeying), when membership changes. A key management scheme (rekeying), when membership changes. A key management scheme
performs the actual distribution of the updated keying material to performs the actual distribution of the updated keying material to
the group. In particular, the key management scheme rekeys the the group. In particular, the key management scheme rekeys the
current group members when a new node joins the group, and the current group members when a new node joins the group, and the
remaining group members when a node leaves the group. This document remaining group members when a node leaves the group. Rekeying
provides a message format for group rekeying that allows to fulfill mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627].
these requirements. Rekeying mechanisms can be based on [RFC2093],
[RFC2094] 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. These "OPTIONAL" in this document are to be interpreted as described in BCP
words may also appear in this document in lowercase, absent their 14 [RFC2119] [RFC8174] when, and only when, they appear in all
normative meanings. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as
Authorization Server (AS) and Resource Server (RS). Authorization Server (AS) and Resource Server (RS).
This document additionally uses the following terminology: This document additionally uses the following terminology:
o Transport profile, to indicate a profile of ACE as per o Transport profile, to indicate a profile of ACE as per
Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. That is, a Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport
transport profile specifies the communication protocol and profile specifies the communication protocol and communication
communication security protocol between an ACE Client and Resource security protocol between an ACE Client and Resource Server, as
Server, as well as proof-of-possession methods, if it supports well as proof-of-possession methods, if it supports proof-of-
proof-of-possession access tokens. Tranport profiles of ACE possession access tokens, etc. Tranport profiles of ACE include,
include, for instance, [I-D.ietf-ace-oscore-profile], for instance, [I-D.ietf-ace-oscore-profile],
[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile].
o Application profile, to indicate a profile of ACE that defines how o Application profile, that defines how applications enforce and use
applications enforce and use supporting security services they supporting security services they require. These services may
require. These services include, for instance, provisioning, include, for instance, provisioning, revocation and
revocation and (re-)distribution of keying material. An (re-)distribution of keying material. An application profile may
application profile may define specific procedures and message define specific procedures and message formats.
formats.
2. Overview 2. Overview
+------------+ +-----------+ +------------+ +-----------+
| AS | | KDC | | AS | | KDC |
| | .-------->| | | | .-------->| |
+------------+ / +-----------+ +------------+ / +-----------+
^ / ^ /
| / | /
v / +-----------+ v / +-----------+
skipping to change at page 5, line 16 skipping to change at page 4, line 52
o Dispatcher: entity through which the Clients communicate with the o Dispatcher: entity through which the Clients communicate with the
group and which distributes messages to the group members. group and which distributes messages to the group members.
Examples of dispatchers are: the Broker node in a pub-sub setting; Examples of dispatchers are: the Broker node in a pub-sub setting;
a relayer node for group communication that delivers group a relayer node for group communication that delivers group
messages as multiple unicast messages to all group members; an messages as multiple unicast messages to all group members; an
implicit entity as in a multicast communication setting, where implicit entity as in a multicast communication setting, where
messages are transmitted to a multicast IP address and delivered messages are transmitted to a multicast IP address and delivered
on the transport channel. on the transport channel.
This document specifies the message flows and formats for: This document specifies a mechanism for:
o Authorizing a new node to join the group (Section 3), and o Authorizing a new node to join the group (Section 3), and
providing it with the group keying material to communicate with providing it with the group keying material to communicate with
the other group members (Section 4). the other group members (Section 4).
o Removing of a current member from the group (Section 5). o A node to leave the group of for the KDC to remove a current
member of the group (Section 5).
o Retrieving keying material as a current group member (Section 6 o Retrieving keying material as a current group member (Section 4.3
and Section 7). 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.2 and Section 5). upon a membership change in the group (Section 4.8 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. node joining a group communication setting.
C AS KDC Dispatcher Group C AS KDC Group
| | | | Member | | | Member
| | | | \ | / | | | |
| Authorization Request | | | | Defined | | | Authorization Request | | |
|----------------------------->| | | | in the ACE | Defined | |---------------------------->| | |
| | | | | framework | in the | | | | |
| Authorization Response | | | | | ACE | | Authorization Response | | |
|<-----------------------------| | | | | framework | |<----------------------------| | |
| | | | | | | | | |
|--------- Token Post ---------------->| | / | \ |----------- Token Post ---------->| |
| | | | | | |
|---- Key Distribution Request ------->| | | |-------- Joining Request -------->| |
| | | | | | |
|<--- Key Distribution Response ------ | --- Group Rekeying ----->| |<------- Joining Response --------|-- Group Rekeying -->|
| | | | | |
|<================== Protected communication ===|================>| | Dispatcher |
| | | | | |
|<====== 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 Key Distribution Request and Key Distribution The exchange of Joining Request and Joining Response between Client
Response between Client and KDC MUST be secured, as a result of the and KDC MUST be secured, as a result of the transport profile of ACE
transport profile of ACE used between Client and KDC. used between Client and KDC.
All further communications between the Client and the KDC MUST be All further communications between the Client and the KDC MUST be
secured, for instance with the same security mechanism used for the secured, for instance with the same security mechanism used for the
Key Distribution exchange. Key Distribution exchange.
All communications between a Client and the other group members MUST All communications between a Client and the other group members MUST
be secured using the keying material provided in Section 4. be secured using the keying material provided in Section 4.
3. Authorization to Join a Group 3. Authorization to Join a Group
This section describes in detail the format of messages exchanged by This section describes in detail the format of messages exchanged by
the participants when a node requests access to a group. The first the participants when a node requests access to a group. This
part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz]. exchange is based on ACE [I-D.ietf-ace-oauth-authz].
As defined in [I-D.ietf-ace-oauth-authz], the Client requests from As defined in [I-D.ietf-ace-oauth-authz], the Client requests from
the AS an authorization to join the group through the KDC (see the AS an authorization to join the group through the KDC (see
Section 3.1). If the request is approved and authorization is Section 3.1). If the request is approved and authorization is
granted, the AS provides the Client with a proof-of-possession access granted, the AS provides the Client with a proof-of-possession access
token and parameters to securely communicate with the KDC (see token and parameters to securely communicate with the KDC (see
Section 3.2). Communications between the Client and the AS MUST be Section 3.2).
secured, according to the transport profile of ACE used. The
Content-Format used in the messages is the one specified by the used Communications between the Client and the AS MUST be secured, as
transport profile of ACE (e.g. application/ace+cbor for the first two defined by the transport profile of ACE used. The Content-Format
messages and application/cwt for the third message, depending on the used in the messages is the one specified by the used transport
format of the access token). profile of ACE (e.g. application/ace+cbor for the first two messages
and application/cwt for the third message, depending on the format of
the access token). The transport profile of ACE also defines a
number of details such as the communication and security protocols
used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]).
Figure 3 gives an overview of the exchange described above. Figure 3 gives an overview of the exchange described above.
Client AS KDC Client AS KDC
| | | | | |
|---- Authorization Request: POST /token ------>| | |---- Authorization Request: POST /token ------>| |
| | | | | |
|<--- Authorization Response: 2.01 (Created) ---| | |<--- Authorization Response: 2.01 (Created) ---| |
| | | | | |
|----- POST Token: POST /authz-info --------------->| |----- POST Token: POST /authz-info --------------->|
| | | |
Figure 3: Message Flow of Join Authorization Figure 3: Message Flow of Join Authorization
3.1. Authorization Request 3.1. Authorization Request
The Authorization Request sent from the Client to the AS is 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 MUST defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY
contain the following parameters: contain the following parameters, which, if included, MUST have the
corresponding values:
o 'grant_type', with value "client_credentials".
Additionally, the Authorization Request MAY contain the following
parameters, which, if included, MUST have the corresponding values:
o 'scope', containing the identifier of the specific group (or topic o 'scope', containing the identifier of the specific group (or topic
in the case of pub-sub) that the Client wishes to access, and in the case of pub-sub) that the Client wishes to access, and
optionally the role(s) that the Client wishes to take. This value optionally the role(s) that the Client wishes to take. This value
is a CBOR array encoded as a byte string, which contains: is a CBOR array encoded as a byte string, 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) the Client wishes to take in the group.
The encoding of the group or topic identifier and of the role The encoding of the group or topic identifier (REQ1) and of the
identifiers is application specific. role identifiers (REQ2) is application specific, and part of the
requirements for the application profile.
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
the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" defined in Section 8.14 of
[I-D.ietf-ace-oauth-authz] is used.
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
skipping to change at page 8, line 29 skipping to change at page 8, line 24
Request (see Section 3.1). Its value is a CBOR array encoded as a Request (see Section 3.1). Its value is a CBOR array encoded as a
byte string, containing: byte string, containing:
* As first element, the identifier of the specific group or topic * As first element, the identifier of the specific group or topic
the Client is authorized to access. the Client is authorized to access.
* Optionally, as second element, the role (or CBOR array of * Optionally, as second element, the role (or CBOR array of
roles) the Client is authorized to take in the group. roles) the Client is authorized to take in the group.
The encoding of the group or topic identifier and of the role The encoding of the group or topic identifier and of the role
identifiers is application specific. 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
the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" is used.
When receiving an Authorization Request from a Client that was When receiving an Authorization Request from a Client that was
previously authorized, and which still owns a valid non expired previously authorized, and which still owns a valid non expired
access token, the AS replies with an Authorization Response with a access token, the AS replies with an Authorization Response with a
new access token. new access token.
3.3. Token Post 3.3. Token Post
The Client sends a CoAP POST request including the access token to The Client sends a CoAP POST request including the access token to
the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
If the specific transport profile of ACE defines it, the Client MAY If the specific transport profile of ACE defines it, the Client MAY
use a different endpoint than /authz-info at the KDC to post the use a different endpoint than /authz-info at the KDC to post the
access token to. access token to.
Optionally, the Client might need to request necessary information Optionally, the Client might want to request necessary information
concerning the public keys in the group, as well as concerning the concerning the public keys in the group, as well as concerning the
algorithm and related parameters for computing signatures in the algorithm and related parameters for computing signatures in the
group. In such a case, the joining node MAY ask for that information group. In such a case, the joining node MAY ask for that information
to the KDC in this same request. To this end, it sends the CoAP POST to the KDC in this same request. To this end, it sends the CoAP POST
request to the /authz-info endpoint using the Content-Format request to the /authz-info endpoint using the Content-Format
"application/ace+cbor" defined in Section 8.14 of "application/ace+cbor". The payload of the message MUST be formatted
[I-D.ietf-ace-oauth-authz], and includes also the following as a CBOR map, including the access token and the following
parameters: parameters:
o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple
value Null, to require information and parameters on the signature value Null, to require information and parameters on the signature
algorithm and on the public keys used in the group. algorithm and on the public keys used in the group.
o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple
value Null, to require information on the exact encoding of public value Null, to require information on the exact encoding of public
keys used in the group. keys used in the group.
skipping to change at page 9, line 39 skipping to change at page 9, line 36
Alternatively, the joining node may retrieve this information by Alternatively, the joining node may retrieve this information by
other means. other means.
After successful verification, the Client is authorized to receive After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group. In the group keying material from the KDC and join the group. In
particular, the KDC replies to the Client with a 2.01 (Created) particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz]. Section 8.14 of [I-D.ietf-ace-oauth-authz].
The payload of the 2.01 response is a CBOR map, which MUST include a The payload of the 2.01 response is a CBOR map, which MUST include
nonce N generated by the KDC. The Client may use this nonce for the parameter 'rsnonce' defined in Section Section 3.3.3, specifying
proving the possession of its own private key (see the a dedicated nonce N_S generated by the KDC. The Client may use this
nonce for proving possession of its own private key (see the
'client_cred_verify' parameter in Section 4). 'client_cred_verify' parameter in Section 4).
Optionally, if they were included in the request, the AS MAY include Optionally, if they were included in the request, the AS 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.
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 for
this parameter. this parameter (REQ3).
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. If no parameters of the specific values for this parameter (REQ4). If no parameters of
signature algorithm are specified, 'sign_parameters' MUST be the signature algorithm are specified, 'sign_parameters' MUST be
encoding 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
depends on the value of 'sign_alg'. It is required of the depends on the value of 'sign_alg'. It is REQUIRED of the
application profiles to define specific values for this parameter. application profiles to define specific values for this parameter
If no parameters of the key used with the signature algorithm are (REQ5). If no parameters of the key used with the signature
specified, 'sign_key_parameters' MUST be encoding the CBOR simple algorithm are specified, 'sign_key_parameters' MUST be encoded as
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 a CBOR the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR
integer, indicating the encoding of public keys used in the group. integer, indicating the encoding of public keys used in the group.
The values of this field are registered in the "ACE Public Key Its acceptable values are taken from the "CWT Confirmation Method"
Encoding" Registry, defined in Section 11.2. It is required of the Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is
application profiles to define specific values to use for this REQUIRED of the application profiles to define specific values to use
parameter. 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,
sign_parameters : any / nil, sign_parameters : any / nil,
sign_key_parameters : any / nil sign_key_parameters : any / nil
] ]
pub_key_enc_res = int pub_key_enc_res = int
Note that the CBOR map specified as payload of the 2.01 (Created) Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g. according to the response may include further parameters, e.g. according to the
signalled transport profile of ACE. signalled transport profile of ACE.
Note that this step could be merged with the following message from
the Client to the KDC, namely Key Distribution Request.
3.3.1. 'sign_info' Parameter 3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the AS Request The 'sign_info' parameter is an OPTIONAL parameter of the AS Request
Creation Hints message defined in Section 5.1.2. of Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information and [I-D.ietf-ace-oauth-authz]. This parameter contains information and
parameters about the signature algorithm and the public keys to be parameters about the signature algorithm and the public keys to be
used between the Client and the RS. Its exact content is application used between the Client and the RS. Its exact content is application
specific. specific.
In this specification and in application profiles building on it,
this parameter is used to ask and retrieve from the KDC information
about the signature algorithm and related parameters used in the
group.
3.3.2. 'pub_key_enc' Parameter 3.3.2. 'pub_key_enc' Parameter
The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS
Request Creation Hints message defined in Section 5.1.2. of Request Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information [I-D.ietf-ace-oauth-authz]. This parameter contains information
about the exact encoding of public keys to be used between the Client about the exact encoding of public keys to be used between the Client
and the RS. Its exact content is application specific. and the RS. Its exact content is application specific.
4. Key Distribution In this specification and in application profiles building on it,
this parameter is used to ask and retrieve from the KDC information
about the encoding of public keys used in the group.
This section defines how the keying material used for group 3.3.3. 'rsnonce' Parameter
communication is distributed from the KDC to the Client, when joining
the group as a new member.
If not previously established, the Client and the KDC MUST first The 'rsnonce' parameter is an OPTIONAL parameter of the AS Request
establish a pairwise secure communication channel using ACE. The Creation Hints message defined in Section 5.1.2. of
exchange of Key Distribution Request-Response MUST occur over that [I-D.ietf-ace-oauth-authz]. This parameter contains a nonce
secure channel. The Client and the KDC MAY use that same secure generated by the RS and provided to the Client. Its exact content is
channel to protect further pairwise communications, that MUST be application specific.
secured.
During this exchange, the Client sends a request to the AS, In this specification and in application profiles building on it,
specifying the group it wishes to join (see Section 4.1). Then, the this parameter is used to provide a nonce that the Client may use to
KDC verifies the access token and that the Client is authorized to prove possession of its own private key in the Joining Request ((see
join that group; if so, it provides the Client with the keying the 'client_cred_verify' parameter in Section 4).
material to securely communicate with the member of the group (see
Section 4.2). The Content-Format used in the messages is set to
application/cbor.
Figure 4 gives an overview of the exchange described above. 4. Keying Material Provisioning and Group Membership Management
Client KDC This section defines the interface available at the KDC. Moreover,
| | this section specifies how the clients can use this interface to join
|---- Key Distribution Request: POST /group-id --->| a group, leave a group, retrieve new keying material or policies.
| |
|<--- Key Distribution Response: 2.01 (Created) ---|
| |
Figure 4: Message Flow of Key Distribution to a New Group Member During the first exchange with the KDC ("Joining"), the Client sends
a request to the KDC, specifying the group it wishes to join (see
Section 4.2). Then, the KDC verifies the access token and that the
Client is authorized to join that group. If so, it provides the
Client with the keying material to securely communicate with the
other members of the group. Whenever used, the Content-Format in
messages containing a payload is set to application/cbor.
The same set of message can also be used for the following cases, TODO: Do we need to define a new Content-Format cbor+ace-groupcomm?
when the Client is already a group member:
o The Client wishes to (re-)get the current keying material, for When the Client is already a group member, the Client can use the
cases such as expiration, loss or suspected mismatch, due to e.g. interface at the KDC to perform the following actions:
reboot or missed group rekeying. This is further discussed in
Section 6.
o The Client wishes to (re-)get the public keys of other group o The Client can (re-)get the current keying material, for cases
members, e.g. if it is aware of new nodes joining the group after such as expiration, loss or suspected mismatch, due to e.g. reboot
itself. This is further discussed in Section 7. or missed group rekeying. This is described in Section 4.3.
Additionally, the format of the payload of the Key Distribution o The Client can retrieve a new individual key, or new input
Response (Section 4.2) can be reused for messages sent by the KDC to material to derive it. This is described in Section 4.4.
distribute updated group keying material, in case of a new node
joining the group or of a current member leaving the group. The key
management scheme used to send such messages could rely on, e.g.,
multicast in case of a new node joining or unicast in case of a node
leaving the group.
Note that proof-of-possession to bind the access token to the Client o The Client can (re-)get the public keys of other group members,
is performed by using the proof-of-possession key bound to the access e.g. if it is aware of new nodes joining the group after itself.
token for establishing secure communication between the Client and This is described in Section 4.5.
the KDC.
If the application requires backward security, the KDC SHALL generate o The Client can (re-)get the policies currently enforced in the
new group keying material and securely distribute it to all the group. This is described in Section 4.6.
current group members, using the message format defined in this
section. Application profiles may define alternative message
formats.
4.1. Key Distribution Request 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.
The Client sends a Key Distribution Request to the KDC. This o The Client can request to leave the group. This is further
corresponds to a CoAP POST request to the endpoint in the KDC discussed in Section 4.8.
associated to the group to join. The endpoint in the KDC is
associated to the 'scope' value of the Authorization Request/
Response. The payload of this request is a CBOR map which MUST
contain the following fields:
o 'type', encoded as a CBOR int, with value 1 ("key distribution"). 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
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
that Client for the group identifier at hand, the KDC MUST respond to
the Client with a 4.01 (Unauthorized) error message.
Additionally, the CBOR map in the payload MAY contain the following 4.1. Interface at KDC
fields, which, if included, MUST have the corresponding values:
The KDC is configured with the following resources:
o /ace-group : this resource is fixed and indicates that this
specification is used. Other applications that run on a KDC
implementing this specification MUST NOT use this same resource.
o /ace-group/gid : one sub-resource to /ace-group is implemented for
each group the KDC manages. These resources are identified by the
group identifiers of the groups the KDC manages (in this example,
the group identifier has value "gid"). These resources support
GET and POST method.
o /ace-group/gid/pub-key : this sub-resource is fixed and supports
GET and POST methods.
o /ace-group/gid/policies: this sub-resource is fixed and supports
the GET method.
o /ace-group/gid/ctx-num: this sub-resource is fixed and supports
the GET method.
o /ace-group/gid/node: this sub-resource is fixed and supports GET
and POST methods.
The details for the handlers of each resource are given in the
following sections. These endpoints are used to perform the
operations introduced in Section 4. Note that the url-path given
here are default names: implementations are not required to use these
names, and can define their own instead.
4.1.1. ace-group
No handlers are implemented for this resource.
4.1.2. ace-group/gid
This resource implements GET and POST handlers.
4.1.2.1. POST Handler
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
material for the group identified by "gid".
The handler expects a request with payload formatted as a CBOR map
which MAY contain the following fields, which, if included, MUST have
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. encoded as 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
Client, encoded as a CBOR byte string. If the KDC is managing Client, encoded as a CBOR byte string. If the KDC is managing
(collecting from/distributing to the Client) the public keys of (collecting from/distributing to the Client) the public keys of
the group members, this field contains the public key of the the group members, this field contains the public key of the
Client. The default encoding for public keys is COSE Keys. Client. The default encoding for public keys is COSE Keys.
Alternative specific encodings of this parameter MAY be defined in Alternative specific encodings of this parameter MAY be defined in
applications of this specification. applications of this specification (OPT1).
o 'cnonce', as defined in Section 5.1.2 of
[I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C
generated by the Client. This parameter MUST be present if the
'client_cred' parameter is present.
o 'client_cred_verify', encoded as a CBOR byte string. This o 'client_cred_verify', encoded as a CBOR byte string. This
parameter contains a signature computed by the Client over the parameter MUST be present if the 'client_cred' parameter is
nonce N received from the KDC in the 2.01 (Created) response to present. This parameter contains a signature computed by the
the token POST request (see Section 3.3). The Client computes the Client over N_S concatenated with N_C, where N_S is the nonce
signature by using its own private key, whose corresponding public received from the KDC in the 'rsnonce' parameter of the 2.01
key is either directly specified in the 'client_cred' parameter or (Created) response to the token POST request (see Section 3.3),
while N_C is the nonce generated by the Client and specified in
the 'cnonce' parameter above. The Client computes the signature
by using its own private key, whose corresponding public key is
either directly specified in the 'client_cred' parameter or
included in the certificate specified in the 'client_cred' included in the certificate specified in the 'client_cred'
parameter. This parameter MUST be present if the 'client_cred' parameter.
parameter is present.
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 a list of public key the 'client_cred' field, with value a list of public key
repositories storing the certificate of the Client. This repositories storing the certificate of the Client. This
parameter is encoded as a CBOR array of CBOR text strings, each of parameter is encoded as a CBOR array of CBOR text strings, each of
which specifies the URI of a key repository. which specifies the URI of a key repository.
4.2. Key Distribution Response The handler verifies that the group identifier of the /ace-group/gid
path is a subset of the 'scope' stored in the access token associated
The KDC verifies that the 'scope' received in the Key Distribution to this client. If verification fails, the KDC MUST respond with a
Request, if present, is a subset of the 'scope' stored in the access 4.01 (Unauthorized) error message.
token associated to this client. If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.
If the Key Distribution Request is not formatted correctly (e.g. no If the request is not formatted correctly (e.g. unknown fields
'scope' field present while expected, or unknown fields present), the present), the handler MUST respond with 4.00 (Bad Request) error
KDC MUST respond with 4.00 (Bad Request) error message. message.
If verification succeeds, the KDC sends a Key Distribution success If verification succeeds, the handler adds the public key indicated
Response to the Client. The Key Distribution success Response in "client_cred" to the list of public keys stored for the group
corresponds to a 2.01 Created message. The payload of this response identified by "gid". The handler returns a 2.01 (Created) message
is a CBOR map, which MUST contain: containing the symmetric group keying material, the group policies
and all the public keys of the current members of the group, if the
KDC manages those and the Client requested them. The payload of the
response is formatted as a CBOR map which MAY contain the following
fields, which, if included, MUST have the corresponding values:
o 'kty', identifying the key type of the 'key' parameter. The set o 'kty', 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.
o 'num', containing the version number of the keying material for
the group communication, formatted as an integer. The initial
version MUST be set to 0 at the KDC.
The exact format of the 'key' value MUST be defined in applications The exact format of the 'key' value MUST be defined in applications
of this specification. Additionally, documents specifying the key of this specification (REQ7), as well as accepted values of 'kty' by
format MUST register it in the "ACE Groupcomm Key" registry, the application (REQ8). Additionally, documents specifying the key
including its name, type and application profile to be used with, as format MUST register it in the "ACE Groupcomm Key" registry defined
defined in the "ACE Groupcomm Key" registry, defined in Section 11.5. in Section 8.3, including its name, type and application profile to
be used with.
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Name | Key Type Value | Profile | Description | | Name | Key Type Value | Profile | Description |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Reserved | 0 | | This value is reserved | | Reserved | 0 | | This value is reserved |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
Figure 5: Key Type Values Figure 4: Key Type Values
Optionally, the Key Distribution Response MAY contain the following Optionally, the response MAY contain the following parameters, which,
parameters, which, if included, MUST have the corresponding values: if included, MUST have the corresponding values:
o 'profile', with value a CBOR integer that MUST be used to uniquely o 'profile', with value a CBOR integer that MUST be used to uniquely
identify the application profile for group communication. The identify the application profile for group communication. The
value MUST be registered in the "ACE Groupcomm Profile" Registry. value MUST be registered in the "ACE Groupcomm Profile" Registry.
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 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 Key Distribution Request. This parameter is a CBOR byte the request. This parameter is a CBOR byte string, which encodes
string, which encodes the public keys of all the group members the public keys of all the group members paired with the
paired with the respective member identifiers. The default respective member identifiers. The default encoding for public
encoding for public keys is COSE Keys, so the default encoding for keys is COSE Keys, so the default encoding for 'pub_keys' is a
'pub_keys' is a CBOR byte string wrapping a COSE_KeySet (see CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which
[RFC8152]), which contains the public keys of all the members of contains the public keys of all the members of the group. In
the group. In particular, each COSE Key in the COSE_KeySet particular, each COSE Key in the COSE_KeySet includes the
includes the identifier of the corresponding group member as value identifier of the corresponding group member as value of its 'kid'
of its 'kid' key parameter. Alternative specific encodings of key parameter. Alternative specific encodings of this parameter
this parameter MAY be defined in applications of this MAY be defined in applications of this specification (OPT2). The
specification. specific format of the identifiers of group members MUST be
specified in the application profile (REQ8).
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 6. Application profiles that build on this summarized in Figure 5. 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. entries (REQ9).
+-----------------+-------+----------|--------------------|------------+ +-----------------+-------+----------|--------------------|------------+
| 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 Number | TBD1 | tstr/int | Method for a re- | [[this |
| Synchronization | | | cipient node to | document]] | | Synchronization | | | cipient node to | document]] |
| Method | | | synchronize with | | | Method | | | synchronize with | |
| | | | sequence numbers | | | | | | sequence numbers | |
| | | | of a sender node. | | | | | | of a sender node. | |
skipping to change at page 15, line 41 skipping to change at page 17, line 28
| | | | 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 Interval | | | in seconds, to | document]] |
| | | | check for new | | | | | | check for new | |
| | | | keying material at | | | | | | keying material at | |
| | | | the KDC | | | | | | the KDC | |
+-----------------+-------+----------|--------------------|------------+ +-----------------+-------+----------|--------------------|------------+
Figure 6: ACE Groupcomm Policies Figure 5: 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 exact format and content rekeying performed by the KDC. The exact format and content
depend on the specific rekeying scheme used in the group, which depend on the specific rekeying scheme used in the group, which
may be specified in the application profile. MAY be specified in the application profile (OPT3).
Specific application profiles that build on this document need to Specific application profiles that build on this document MUST
specify how exactly the keying material is used to protect the group specify how exactly the keying material is used to protect the group
communication. communication (REQ10).
5. Removal of a Node from the Group CBOR labels for these fields are defined in Section 6.
This section describes at a high level how a node can be removed from 4.1.2.2. GET Handler
the group.
If the application requires forward security, the KDC SHALL generate The GET handler returns the symmetric group keying material for the
new group keying material and securely distribute it to all the group identified by "gid".
current group members but the leaving node, using the message format
defined in Section 4.2. Application profiles may define alternative
message formats.
5.1. Expired Authorization The handler expects a GET request.
If the AS provides Token introspection (see Section 5.7 of The handler verifies that the group identifier of the /ace-group/gid
[I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check path is a subset of the 'scope' stored in the access token associated
whether: to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message.
o the node is not authorized anymore; If verification succeeds, the handler returns a 2.05 (Content)
message containing the symmetric group keying material, the group
policies and all the public keys of the current members of the group.
The payload of the response is formatted as a CBOR map which MUST
contain the parameters 'kty','key' and 'num' specified in
Section 4.1.2.1.
o the access token is still valid, upon its expiration. The payload MAY also include the parameters 'profile', 'exp' and
'mgt_key_material' parameters specified in Section 4.1.2.1.
Either case, once aware that a node is not authorized anymore, the 4.1.3. ace-group/gid/pub-key
KDC has to remove the unauthorized node from the list of group
members, if the KDC keeps track of that.
5.2. Request to Leave the Group This resource implements GET and POST handlers.
A node can actively request to leave the group. In this case, the 4.1.3.1. POST Handler
Client can send a request formatted as follows to the KDC, to abandon
the group. The client MUST use the protected channel established
with ACE, mentioned in Section 4.
To request to leave a group, the client MUST send a CoAP POST request The POST handler receives identifiers of group members for the group
to the endpoint in the KDC associated to the group to leave (same identified by "gid" and returns the public keys of such group
endpoint used in Section 4.1 for Key Distribution requests). The members.
payload of this Leave Request is a CBOR map which MUST contain:
o 'type', encoded as a CBOR int, with value 2 ("leave"). The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MUST contain the
following fields:
o 'scope', with value the specific resource that the Client is o 'get_pub_keys', whose value is a non-empty CBOR array. Each
authorized to access (i.e. group or topic identifier) and wants to element of the array is the identifier of a group member for the
leave, encoded as in Section 3.1. The 'role' field is omitted. group identified by "gid". The specific format of public keys as
well as identifiers of group members MUST be specified by the
application profile (REQ11, REQ8).
Note that the 'role' field is omitted since such a request should The handler verifies that the group identifier of the /ace-group/gid
only be used to leave a group altogether. If the leaving node wants path is a subset of the 'scope' stored in the access token associated
to be part of a group with fewer roles, it does not need to to this client. If verification fails, the KDC MUST respond with a
communicate that to the KDC, and can simply stop acting according to 4.01 (Unauthorized) error message.
such roles.
If the Leave Request is such that the KDC cannot extract all the The handler verifies that the 'get_pub_keys' parameter is not an
necessary information to understand and process it correctly (e.g. no empty CBOR Array. If verification fails, the KDC MUST treat the
'scope' field present), the KDC MUST respond with a 4.00 (Bad request as malformed and respond with a 4.00 (Bad Request) error
Request) error message. Otherwise, the KDC MUST remove the leaving message.
node from the list of group members, if the KDC keeps track of that.
Note that, after having left the group, a node may wish to join it If verification succeeds, the handler identifies the public keys of
again. Then, as long as the node is still authorized to join the the current group members for which the identifier matches with one
group, i.e. it has a still valid access token, it can re-request to of those indicated in the request. Then, the handler returns a 2.05
join the group directly to the KDC without needing to retrieve a new (Content) message response with payload formatted as a CBOR map
access token from the AS. This means that the KDC needs to keep containing only the 'pub_keys' parameter from Section 4.1.2.1, which
track of nodes with valid access tokens, before deleting all encodes the list of public keys of those group members including the
information about the leaving node. respective member identifiers. If the KDC does not store any public
key associated with the 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
(REQ11, REQ8).
6. Retrieval of New or Updated Keying Material The handler MAY enforce one of the following policies, in order to
handle possible identifiers that are included in the 'get_pub_keys'
parameter of the request but are not associated to any current group
member. Such a policy MUST be specified by the application profile
(REQ12)
o The KDC silently ignores those identifiers.
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
public keys are retained, the KDC provides them to a requesting
Client.
4.1.3.2. GET Handler
The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid
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.
If verification succeeds, the handler returns a 2.05 (Content)
message containing the public keys of all the current group members,
for the group identified by "gid". The payload of the response is
formatted as a CBOR map containing only the 'pub_keys' parameter from
Section 4.1.2.1, which encodes the list of public keys of all the
group members including the respective member identifiers. 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 (REQ11,
REQ8).
4.1.4. ace-group/gid/policies
This resource implements a GET handler.
4.1.4.1. GET Handler
The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid
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.
If verification succeeds, the handler returns a 2.05 (Content)
message containing the list of policies for the group identified by
"gid". The payload of the response is formatted as a CBOR map
including only the parameter 'group_policies' defined in
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
zero-length CBOR byte string.
The specific format and meaning of group policies MUST be specified
in the application profile (REQ13).
4.1.5. ace-group/gid/ctx-num
This resource implements a GET handler.
4.1.5.1. GET Handler
The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid
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.
If verification succeeds, the handler returns a 2.05 (Content)
message containing an integer that represents the version number of
the symmetric group keying material. This number is incremented on
the KDC every time the KDC updates the symmetric group keying
material. The payload of the response is formatted as a CBOR
integer.
4.1.6. ace-group/gid/node
This resource implements GET and POST handlers.
4.1.6.1. POST Handler
The POST handler removes the node from the group, for the group
identified by "gid".
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
'scope' field as specified in Section 4.1.2.1.
The handler verifies that the group identifier of the /ace-group/gid
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.
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
extract all the necessary information to understand and process it
correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00
(Bad Request) error message.
If verification succeeds, the handler removes the client from the
group identified by "gid", for specific roles if roles were specified
in the 'scope' field, or for all roles. That includes removing the
public key of the client if the KDC keep tracks of that. Then, the
handler returns a 2.05 (Content) message with empty payload.
4.1.6.2. GET Handler
The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid
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.
If verification succeeds, the handler returns a 2.05 (Content)
message containing newly-generated individual keying material for the
Client, or information enabling the Client to derive it. The payload
of the response is formatted as a CBOR map. The specific format of
newly-generated individual keying material for group members, or of
the information to derive it, and corresponding CBOR label, MUST be
specified in the application profile (REQ14) and registered in
Section 8.2.
4.2. Joining Exchange
Figure 6 gives an overview of the Joining exchange between Client and
KDC, when the Client first joins a group.
Client KDC
| |
|-------- Joining Request: POST /ace-group/gid --------->|
| |
|<--------- Joining Response: 2.01 (Created) ----------- |
| |
Figure 6: Message Flow of First Exchange for Group Joining
If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel (REQ15). This can
be achieved, for instance, by using a transport profile of ACE. The
Joining exchange MUST occur over that secure channel. The Client and
the KDC MAY use that same secure channel to protect further pairwise
communications that must be secured.
The secure communication protocol is REQUIRED to establish the secure
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
to the Client is performed by using the proof-of-possession key bound
to the access token for establishing secure communication between the
Client and the KDC.
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
the group to join, formatted as specified in Section 4.1.2.1. This
group identifier is the same as the 'scope' value of the
Authorization Request/Response, or it can be retrieved from it.
If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the
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
Section 4.1.2.1). Application profiles may define alternative ways
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,
Section 4.1.4.1). After distributing the new group keying material,
the KDC MUST increment the version number of the keying material.
4.3. Retrieval of Updated Keying Material
A node stops using the group keying material upon its expiration, A node stops using the group keying material upon its expiration,
according to the 'exp' parameter specified in the retained COSE Key. according to what indicated by the KDC with the 'exp' parameter in a
Then, if it wants to continue participating in the group Joining response, or to a pre-configured value. Then, if it wants to
communication, the node has to request new updated keying material to continue participating in the group communication, the node has to
the KDC. In this case, and depending on what part of the keying request new updated keying material from the KDC.
material is expired, the client may need to communicate to the KDC
its need for that part to be renewed: for example, if the Client uses
an individual key to protect outgoing traffic and has to renew it,
the node may request a new one, or new input material to derive it,
without renewing the whole group keying material.
The Client may perform the same request to the KDC also upon The Client may need to request the latest group keying material also
receiving messages from other group members without being able to upon receiving messages from other group members without being able
retrieve the material to correctly decrypt them. This may be due to to retrieve the material to correctly decrypt them. This may be due
a previous update of the group keying material (rekeying) triggered to a previous update of the group keying material (rekeying)
by the KDC, that the Client was not able to receive or decrypt. 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 endpoint at the KDC, formatted as specified in
Section 4.1.2.2.
Note that policies can be set up so that the Client sends a request Note that policies can be set up so that the Client sends a Key Re-
to the KDC only after a given number of unsuccessfully decrypted Distribution Request to the KDC only after a given number of
incoming messages. It is application dependent and pertaining to the unsuccessfully decrypted incoming messages. It is application
particular message exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) dependent and pertaining to the particular message exchange (e.g.
to set up policies that instruct clients to retain unsuccessfully [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct
decrypted messages and for how long, so that they can be decrypted clients to retain unsuccessfully decrypted messages and for how long,
after getting updated keying material, rather than just considered so that they can be decrypted after getting updated keying material,
non valid messages to discard right away. rather than just considered non valid messages to discard right away
(OPT4).
The same request could also be sent by the client without being The same Key Distribution Request could also be sent by the Client
triggered by a failed decryption of a message, if the client wants to without being triggered by a failed decryption of a message, if the
confirm that it has the latest group keying material. If that is the Client wants to be sure that it has the latest group keying material.
case, the client will receive from the KDC the same group keying If that is the case, the Client will receive from the KDC the same
material it has in memory. group keying material it already has in memory.
Note that the difference between the keying material renewal request Figure 7 gives an overview of the exchange described above.
and the keying material update request is that the first one triggers
the KDC to produce new keying material for that node, while the Client KDC
second one only triggers distribution (the renewal might have | |
happened independently, because of expiration). Once a node receives |----- Key Distribution Request: GET ace-group/gid ----->|
new individual keying material, other group members may need to use | |
the update keying material request to retrieve it. |<----- Key Distribution Response: 2.05 (Content) -------|
| |
Figure 7: 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 maintain an Observable resource to send notifications to o Can make the ace-group/gid resource Observable, and send
Clients when the keying material is updated. Such a notification notifications to Clients when the keying material is updated.
would have the same payload as the Key Re-Distribution Response
defined in Section 6.2.
o Can send the payload of the Key Re-Distribution Response as one or o Can send the Key Distribution Response as one or multiple
multiple multicast requests to the members of the group, using multicast requests to the members of the group, using secure
secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. rekeying schemes such as [RFC2093][RFC2094][RFC2627].
o Can send unicast requests to each Client over a secure channel, o Can send unicast requests to each Client over a secure channel,
with the Key Re-Distribution Response as payload. with the same payload as the Key Distribution Response.
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 re-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.
6.1. Key Re-Distribution Request 4.4. Retrieval of New Keying Material
To request a re-distribution of keying material, the Client sends a Beside possible expiration and depending on what part of the keying
shortened Key Distribution Request to the KDC (Section 4.1), material is no longer eligible to be used, the client may need to
formatted as follows. The payload MUST contain the following fields: communicate to the KDC its need for that part to be renewed. For
example, if the Client uses an individual key to protect outgoing
traffic and has to renew it, the node may request a new one, or new
input material to derive it, without renewing the whole group keying
material. To this end, the client performs a Key Renewal Request/
Response exchange with the KDC, that is a CoAP GET request to the
/ace-group/gid/node endpoint at the KDC, where gid is the group
identifier, and formatted as defined in Section 4.1.6.2.
o 'type', encoded as a CBOR int, with value 3 ("update key") if the Figure 8 gives an overview of the exchange described above.
request is intended to retrieve updated group keying material, and
4 ("new") if the request is intended for the KDC to produce and
provide new individual keying material for the Client.
o 'scope', which contains only the identifier of the specific group Client KDC
or topic, encoded as in Section 3.1. That is, the role field is | |
not present. |---- Key Renewal Request: GET ace-group/gid/node --->|
| |
|<----- Key Renewal Response: 2.05 (Content) ---------|
| |
6.2. Key Re-Distribution Response Figure 8: Message Flow of Key Renewal Request-Response
The KDC receiving a Key Re-Distribution Request MUST check that it is Note the difference between the Key Distribution Request and the Key
storing a valid access token from that client for that scope. Renewal Request: while the first one only triggers distribution (the
renewal might have happened independently, e.g. because of
expiration), the second one triggers the KDC to produce new
individual keying material for the requesting node.
If that is not the case, i.e. it does not store the token or the 4.5. Retrieval of Public Keys for Group Members
token is not valid for that client for the scope requested, the KDC
MUST respond with a 4.01 (Unauthorized) error message. Analogously
to Section 4.2, if the Key Re-Distribution Request is not formatted
correctly (e.g. no 'scope' field present, or unknown fields present),
the KDC MUST respond with a 4.00 (Bad Request) error message.
Otherwise, the KDC replies to the Client with a Key Distribution In case the KDC maintains the public keys of group members, a node in
Response, which MUST include the 'kty', 'key' and 'exp' parameters the group can contact the KDC to request public keys of either all
specified in Section 4.2. The Key Distribution Response MAY also group members or a specified subset, by sending a CoAP GET or POST
include the 'profile', 'group_policies' and 'mgt_key_material' request to the /ace-group/gid/pub-key endpoint at the KDC, where gid
parameters specified in Section 4.2. is the group identifier, and formatted as defined in Section 4.1.3.2
and Section 4.1.3.1.
Note that this response might simply re-provide the same keying Figure 9 and Figure 10 give an overview of the exchanges described
material currently owned by the Client, if it has not been renewed. above.
7. Retrieval of Public Keys for Group Members Client KDC
| |
|---- Public Key Request: GET /ace-group/gid/pub-key --->|
| |
|<--------- Public Key Response: 2.05 (Content) ---------|
| |
In case the KDC maintains the public keys of group members, a node in Figure 9: Message Flow of Public Key Exchange to Request All Members
the group can contact the KDC to request public keys of either all Public Keys
group members or a specified subset, using the messages defined
below.
Figure 7 gives an overview of the exchange described above. Client KDC
| |
|--- Public Key Request: POST /ace-group/gid/pub-key --->|
| |
|<--------- Public Key Response: 2.01 (Created) ---------|
| |
Client KDC Figure 10: Message Flow of Public Key Exchange to Request Specific
| | Members Public Keys
|---- Public Key Request: POST /group-id --->|
| |
|<--- Public Key Response: 2.01 (Created) ---|
| |
Figure 7: Message Flow of Public Key Request-Response 4.6. Retrieval of Group Policies
Note that these messages can be combined with the Key Re-Distribution A node in the group can contact the KDC to retrieve the current group
messages in Section 6, to request at the same time the keying policies, by sending a CoAP GET request to the /ace-group/gid/
material and the public keys. In this case, either a new endpoint at policies endpoint at the KDC, where gid is the group identifier, and
the KDC may be used, or additional information needs to be sent in formatted as defined in Section 4.1.4.1
the request payload, to distinguish these combined messages from the
Public Key messages described below, since they would be identical
otherwise.
7.1. Public Key Request Figure 11 gives an overview of the exchange described above.
To request public keys, the Client sends a shortened Key Distribution Client KDC
Request to the KDC (Section 4.1), formatted as follows. The payload | |
of this request MUST contain the following fields: |--- Policies Request: GET ace-group/gid/policies ---->|
| |
|<--------- Policies Response: 2.05 (Content) ---------|
| |
o 'type', encoded as a CBOR int, with value 5 ("pub keys"). Figure 11: Message Flow of Policies Request-Response
o 'get_pub_keys', which has as value a CBOR array including either: 4.7. Retrieval of Keying Material Version
* no elements, i.e. an empty array, in order to request the A node in the group can contact the KDC to request information about
public key of all current group members; or 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,
where gid is the group identifier, formatted as defined in
Section 4.1.5.1. In particular, the version is incremented by the
KDC every time the group keying material is renewed.
* N elements, each of which is the identifier of a group member Figure 12 gives an overview of the exchange described above.
encoded as a CBOR byte string, in order to request the public
key of the specified nodes.
o 'scope', which contains only the identifier of the specific group Client KDC
or topic, encoded as in Section 3.1. That is, the role field is | |
not present. |----- Version Request: GET ace-group/gid/ctx-num ----->|
| |
|<--------- Version Response: 2.05 (Content) -----------|
| |
7.2. Public Key Response Figure 12: Message Flow of Version Request-Response
The KDC replies to the Client with a Key Distribution Response 4.8. Group Leaving Request
containing only the 'pub_keys' parameter, as specified in
Section 4.2. The payload of this response contains the following
field:
o 'pub_keys', which contains either: A node can actively request to leave the group. In this case, the
Client sends a CoAP POST request to the endpoint /ace-group/gid/node
at the KDC, where gid is the group identifier, formatted as defined
in Section 4.1.6.1
* the public keys of all the members of the group, if the Alternatively, a node may be removed by the KDC, without having
'get_pub_keys' parameter of the Public Key request was an empty explicitly asked for it. This is further discussed in Section 5.
array; or
* the public keys of the group members with the identifiers 5. Removal of a Node from the Group
specified in the 'get_pub_keys' parameter of the Public Key
request.
The KDC may enforce one of the following policies, in order to handle This section describes the different scenarios according to which a
possible identifiers that are included in the 'get_pub_keys' node ends up being removed from the group.
parameter of the Public Key request but are not associated to any
current group member.
o The KDC silently ignores those identifiers. If the application requires forward security, the KDC MUST generate
new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format
of the Key Distribution Response (see Section 4.3). Application
profiles may define alternative message formats. Once distributed
the new group keying material, the KDC MUST increment the version
number of the keying material.
o The KDC retains public keys of group members for a given amount of Note that, after having left the group, a node may wish to join it
time after their leaving, before discarding them. As long as such again. Then, as long as the node is still authorized to join the
public keys are retained, the KDC provides them to a requesting group, i.e. it still has a valid access token, it can re-request to
Client. 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
keep track of nodes with valid access tokens, before deleting all
information about the leaving node.
Either case, a node that has left the group should not expect any of A node may be evicted from the group in the following cases.
its outgoing messages to be successfully processed, if received after
its leaving, due to a possible group rekeying occurred before the
message reception.
8. ACE Groupcomm Parameters 1. The node explicitly asks to leave the group, as defined in
Section 4.8.
This specification defines a number of fields used during the message 2. The node has been found compromised or is suspected so.
exchange. The table below summarizes them, and specifies the CBOR
key to use instead of the full descriptive name.
+--------------+----------+---------------+ 3. The node's authorization to be a group member is expired. If the
| Name | CBOR Key | CBOR Type | AS provides Token introspection (see Section 5.7 of
+--------------+----------+---------------+ [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check
| scope | TBD | array | whether:
+--------------+----------+---------------+
| get_pub_keys | TBD | array |
+--------------+----------+---------------+
| client_cred | TBD | byte string |
+--------------+----------+---------------+
| client_cred_ | TBD | byte string |
| verify | | |
+--------------+----------+---------------+
| pub_keys_ | TBD | array |
| repos | | |
+--------------+----------+---------------+
| kty | TBD | int / byte |
| | | string |
+--------------+----------+---------------+
| key | TBD | see "ACE |
| | | Groupcomm |
| | | Key" Registry |
+--------------+----------+---------------+
| profile | TBD | int |
+--------------+----------+---------------+
| exp | TBD | int / float |
+--------------+----------+---------------+
| pub_keys | TBD | byte string |
+--------------+----------+---------------+
| group_ | TBD | map |
| policies | | |
+--------------+----------+---------------+
| mgt_key_ | TBD | byte string |
| material | | |
+--------------+----------+---------------+
| type | TBD | int |
+--------------+----------+---------------+
9. ACE Groupcomm Request Type * the node is not authorized anymore;
This specification defines a number of types of requests. The table * the access token is still valid, upon its expiration.
below summarizes them.
+------------------+----------+ Either case, once aware that a node is not authorized anymore,
| Name | Value | the KDC has to remove the unauthorized node from the list of
+------------------+----------+ group members, if the KDC keeps track of that.
| key distribution | 1 |
+------------------+----------+
| leave | 2 |
+------------------+----------+
| update key | 3 |
+------------------+----------+
| new | 4 |
+------------------+----------+
| pub keys | 5 |
+------------------+----------+
10. Security Considerations 6. ACE Groupcomm Parameters
This specification defines a number of fields used during the second
part of the message exchange, after the ACE Token POST exchange. The
table below summarizes them, and specifies the CBOR key to use
instead of the full descriptive name.
+--------------------+--------+-----------------------+-------------+
| Name | CBOR | CBOR Type | Reference |
| | Key | | |
+--------------------+--------+-----------------------+-------------+
| scope | TBD | array | Section |
| | | | 4.1.2.1 |
| | | | |
| get_pub_keys | TBD | array | Section |
| | | | 4.1.2.1 |
| | | | |
| client_cred | TBD | byte string | Section |
| | | | 4.1.2.1 |
| | | | |
| cnonce | TBD | byte string | Section |
| | | | 4.1.2.1 |
| | | | |
| client_cred_verify | TBD | byte string | Section |
| | | | 4.1.2.1 |
| | | | |
| pub_keys_repos | TBD | array | Section |
| | | | 4.1.2.1 |
| | | | |
| kty | TBD | int / byte string | Section |
| | | | 4.1.2.1 |
| | | | |
| key | TBD | see "ACE Groupcomm | Section |
| | | Key" Registry | 4.1.2.1 |
| | | | |
| num | TBD | int | Section |
| | | | 4.1.2.1 |
| | | | |
| profile | TBD | int | Section |
| | | | 4.1.2.1 |
| | | | |
| exp | TBD | int / float | Section |
| | | | 4.1.2.1 |
| | | | |
| pub_keys | 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
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 [I-D.ietf-core-object-security]. 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
change, and should provide it to the current group members through change, and should provide it to the current group members through
the rekeying scheme used in the group. the rekeying scheme used in the group.
The KDC may enforce a rekeying policy that takes into account the The KDC may enforce a rekeying policy that takes into account the
overall time required to rekey the group, as well as the expected overall time required to rekey the group, as well as the expected
rate of changes in the group membership. rate of changes in the group membership.
skipping to change at page 24, line 5 skipping to change at page 29, line 9
inactivity periods. inactivity periods.
However, this would result in the KDC not constantly preserving However, this would result in the KDC not constantly preserving
backward and forward security. In fact, newly joining group members backward and forward security. In fact, newly joining group members
could be able to access the keying material used before their could be able to access the keying material used before their
joining, and thus could access past group communications. Also, joining, and thus could access past group communications. Also,
until the KDC performs a group rekeying, the newly leaving nodes until the KDC performs a group rekeying, the newly leaving nodes
would still be able to access upcoming group communications that are would still be able to access upcoming group communications that are
protected with the keying material that has not yet been updated. protected with the keying material that has not yet been updated.
10.1. Update of Keying Material 7.1. Update of Keying Material
A group member can receive a message shortly after the group has been A group member can receive a message shortly after the group has been
rekeyed, and new keying material has been distributed by the KDC. In rekeyed, and new keying material has been distributed by the KDC. In
the following two cases, this may result in misaligned keying the following two cases, this may result in misaligned keying
material between the group members. material between the group members.
In the first case, the sender protects a message using the old keying In the first case, the sender protects a message using the old keying
material. However, the recipient receives the message after having material. However, the recipient receives the message after having
received the new keying material, hence not being able to correctly received the new keying material, hence not being able to correctly
process it. A possible way to ameliorate this issue is to preserve process it. A possible way to ameliorate this issue is to preserve
skipping to change at page 24, line 36 skipping to change at page 29, line 40
having received the new keying material. Therefore, the recipient having received the new keying material. Therefore, the recipient
would not be able to correctly process the request and hence discards would not be able to correctly process the request and hence discards
it. If the recipient receives the new keying material shortly after it. If the recipient receives the new keying material shortly after
that and the sender endpoint uses CoAP retransmissions, the former that and the sender endpoint uses CoAP retransmissions, the former
will still be able to receive and correctly process the message. In will still be able to receive and correctly process the message. In
any case, the recipient should actively ask the KDC for an updated any case, the recipient should actively ask the KDC for an updated
keying material according to an application-defined policy, for keying material according to an application-defined policy, for
instance after a given number of unsuccessfully decrypted incoming instance after a given number of unsuccessfully decrypted incoming
messages. messages.
10.2. Block-Wise Considerations A node that has left the group should not expect any of its outgoing
messages to be successfully processed, if received after its leaving,
due to a possible group rekeying occurred before the message
reception.
7.2. Block-Wise Considerations
If the block-wise options [RFC7959] are used, and the keying material If the block-wise options [RFC7959] are used, and the keying material
is updated in the middle of a block-wise transfer, the sender of the is updated in the middle of a block-wise transfer, the sender of the
blocks just changes the keying material to the updated one and blocks just changes the keying material to the updated one and
continues the transfer. As long as both sides get the new keying continues the transfer. As long as both sides get the new keying
material, updating the keying material in the middle of a transfer material, updating the keying material in the middle of a transfer
will not cause any issue. Otherwise, the sender will have to will not cause any issue. Otherwise, the sender will have to
transmit the message again, when receiving an error message from the transmit the message again, when receiving an error message from the
recipient. recipient.
Compared to a scenario where the transfer does not use block-wise, Compared to a scenario where the transfer does not use block-wise,
depending on how fast the keying material is changed, the nodes might depending on how fast the keying material is changed, the nodes might
consume a larger amount of the network resending the blocks again and consume a larger amount of the network bandwidth resending the blocks
again, which might be problematic. again and again, which might be problematic.
11. IANA Considerations 8. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
11.1. ACE Authorization Server Request Creation Hints Registry 8.1. ACE Authorization Server Request Creation Hints Registry
IANA is asked to register the following entries in the "ACE IANA is asked to register the following entries in the "ACE
Authorization Server Request Creation Hints" Registry defined in Authorization Server Request Creation Hints" Registry defined in
Section 8.1 of [I-D.ietf-ace-oauth-authz]. Section 8.1 of [I-D.ietf-ace-oauth-authz].
o Name: sign_info o Name: sign_info
o CBOR Key: TBD (range -256 to 255) o CBOR Key: TBD (range -256 to 255)
o Value Type: any o Value Type: any
skipping to change at page 25, line 31 skipping to change at page 30, line 39
o Reference: [[This specification]] o Reference: [[This specification]]
o Name: pub_key_enc o Name: pub_key_enc
o CBOR Key: TBD (range -256 to 255) o CBOR Key: TBD (range -256 to 255)
o Value Type: integer o Value Type: integer
o Reference: [[This specification]] o Reference: [[This specification]]
11.2. ACE Public Key Encoding Registry o Name: rsnonce
This specification establishes the "ACE Public Key Encoding" IANA
Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 11.9. It should be noted that, in addition
to the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as
well.
The columns of this Registry are:
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
encoding.
o Value: The value to be used to identify this public key encoding.
This value MUST be unique. The value can be a positive or a
negative integer. Integer values between 0 and 255 are designated
as Standards Track Document required. Integer values from 256 to
65535 are designated as Specification Required. Integer values of
greater than 65535 are designated as expert review. Integer
values less than -65536 are marked as private use.
o Description: This field contains a brief description for this o CBOR Key: TBD (range -256 to 255)
public key encoding.
o Reference: This field contains a pointer to the public o Value Type: byte string
specification providing the public key encoding, if one exists.
The value 0 is to be marked as "Reserved". o Reference: [[This specification]]
11.3. ACE Groupcomm Parameters Registry 8.2. ACE Groupcomm Parameters Registry
This specification establishes the "ACE Groupcomm Parameters" IANA This specification establishes the "ACE Groupcomm Parameters" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 11.9. are provided in Section 8.7.
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 CBOR Key: This is the value used as CBOR key of the item. These o CBOR Key: This is the value used as CBOR key of the item. These
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer, or a string. negative integer, or a string.
o CBOR Type: This contains the CBOR type of the item, or a pointer o CBOR Type: This contains the CBOR type of the item, or a pointer
to the registry that defines its type, when that depends on to the registry that defines its type, when that depends on
another item. another item.
o Reference: This contains a pointer to the public specification for o Reference: This contains a pointer to the public specification for
the format of the item, if one exists. the item.
This Registry has been initially populated by the values in
Section 8. The specification column for all of these entries will be
this document.
11.4. Ace Groupcomm Request Type Registry
This specification establishes the "ACE Groupcomm Request Type" IANA
Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 11.9.
The columns of this Registry are:
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
encoding.
o Value: This is the value used to identify the request. These
values MUST be unique. The value must be a positive integer.
o Reference: This contains a pointer to the public specification for
the format of the item, if one exists.
This Registry has been initially populated by the values in This Registry has been initially populated by the values in
Section 9. The reference column for all of these entries will be Section 6. The Reference column for all of these entries refers to
this document. The value 0 is to be marked as "Reserved". sections of this document.
11.5. ACE Groupcomm Key Registry 8.3. ACE Groupcomm Key Registry
This specification establishes the "ACE Groupcomm Key" IANA Registry. This specification establishes the "ACE Groupcomm Key" IANA Registry.
The Registry has been created to use the "Expert Review Required" The Registry has been created to use the "Expert Review Required"
registration procedure [RFC8126]. Expert review guidelines are registration procedure [RFC8126]. Expert review guidelines are
provided in Section 11.9. provided in Section 8.7.
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 string.
skipping to change at page 27, line 47 skipping to change at page 32, line 8
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 5. This Registry has been initially populated by the values in Figure 4.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document.
11.6. ACE Groupcomm Profile Registry 8.4. 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 11.9. It should be noted that, in addition are provided in Section 8.7. It should be noted that, in addition to
to the expert review, some portions of the Registry require a the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as specification, potentially a Standards Track RFC, be supplied as
well. well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the application profile, to be used as value of o Name: The name of the application profile, to be used as value of
the profile attribute. the profile attribute.
o Description: Text giving an overview of the application profile o Description: Text giving an overview of the application profile
and the context it is developed for. and the context it is developed for.
skipping to change at page 28, line 35 skipping to change at page 32, line 42
policies [RFC8126]. Integer values from -256 to 255 are policies [RFC8126]. Integer values from -256 to 255 are
designated as Standards Action. Integer values from -65536 to designated as Standards Action. Integer values from -65536 to
-257 and from 256 to 65535 are designated as Specification -257 and from 256 to 65535 are designated as Specification
Required. Integer values greater than 65535 are designated as Required. Integer values greater than 65535 are designated as
Expert Review. Integer values less than -65536 are marked as Expert Review. Integer values less than -65536 are marked as
Private Use. Private Use.
o Reference: This contains a pointer to the public specification of o Reference: This contains a pointer to the public specification of
the abbreviation for this application profile, if one exists. the abbreviation for this application profile, if one exists.
11.7. ACE Groupcomm Policy Registry 8.5. ACE Groupcomm Policy Registry
This specification establishes the "ACE Groupcomm Policy" IANA This specification establishes the "ACE Groupcomm Policy" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 11.9. It should be noted that, in addition are provided in Section 8.7. It should be noted that, in addition to
to the expert review, some portions of the Registry require a the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as specification, potentially a Standards Track RFC, be supplied as
well. well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the group communication policy. o Name: The name of the group communication policy.
o CBOR label: The value to be used to identify this group o CBOR label: The value to be used to identify this group
communication policy. Key map labels MUST be unique. The label communication policy. Key map labels MUST be unique. The label
can be a positive integer, a negative integer or a string. can be a positive integer, a negative integer or a string.
skipping to change at page 29, line 20 skipping to change at page 33, line 27
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 6. This registry will be initially populated by the values in Figure 5.
11.8. Sequence Number Synchronization Method Registry 8.6. 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 11.9. It should be noted review guidelines are provided in Section 8.7. It should be noted
that, in addition to the expert review, some portions of the Registry that, in addition to the expert review, some portions of the Registry
require a specification, potentially a Standards Track RFC, be require a specification, potentially a Standards Track RFC, be
supplied as well. supplied as well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the sequence number synchronization method. o Name: The name of the sequence number synchronization method.
o Value: The value to be used to identify this sequence number o Value: The value to be used to identify this sequence number
synchronization method. synchronization method.
o Description: This field contains a brief description for this o Description: This field contains a brief description for this
sequence number synchronization method. sequence number synchronization method.
o Reference: This field contains a pointer to the public o Reference: This field contains a pointer to the public
specification describing the sequence number synchronization specification describing the sequence number synchronization
method. method.
11.9. Expert Review Instructions 8.7. Expert Review Instructions
The IANA Registries established in this document are defined as The IANA Registries established in this document are defined as
expert review. This section gives some general guidelines for what expert review. This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
skipping to change at page 30, line 34 skipping to change at page 34, line 41
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that used on, and the number of code points left that encode to that
size. size.
12. References 9. References
12.1. Normative References 9.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
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-24 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25
(work in progress), March 2019. (work in progress), October 2019.
[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-05 (work in progress), March 2019. params-05 (work in progress), March 2019.
[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-05 (work in progress), draft-ietf-core-oscore-groupcomm-05 (work in progress),
skipping to change at page 31, line 29 skipping to change at page 35, line 41
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
12.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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-00 (work in progress), March 2019. dijk-core-groupcomm-bis-01 (work in progress), July 2019.
[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-08 (work in progress), April 2019. authorize-08 (work in progress), April 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-00 (work in of ACE", draft-ietf-ace-mqtt-tls-profile-01 (work in
progress), May 2019. progress), October 2019.
[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-07 (work in progress), February 2019. oscore-profile-08 (work in progress), July 2019.
[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-08 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), March 2019. progress), September 2019.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 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,
<https://www.rfc-editor.org/info/rfc2093>. <https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997, DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>. <https://www.rfc-editor.org/info/rfc2094>.
skipping to change at page 33, line 5 skipping to change at page 37, line 15
[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
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
Appendix A. Requirements on Application Profiles Appendix A. Requirements on Application Profiles
TODO: fix req numbers in the text.
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 Specify the communication protocol the members of the group must o REQ1: Specify the encoding and value of the identifier of group or
use (e.g., multicast CoAP). topic of 'scope' (see Section 3.1).
o Specify the security protocol the group members must use to o REQ2: Specify the encoding and value of roles of 'scope' (see
Section 3.1).
o REQ3: Optionally, specify the acceptable values for 'sign_alg'
(see Section 3.3).
o REQ4: Optionally, specify the acceptable values for
'sign_parameters' (see Section 3.3).
o REQ5: Optionally, specify the acceptable values for
'sign_key_parameters' (see Section 3.3).
o REQ6: Optionally, specify the acceptable values for 'pub_key_enc'
(see Section 3.3).
o REQ7: Specify the exact format of the 'key' value (see
Section 4.1.2.1).
o REQ8: Specify the acceptable values of 'kty' (see
Section 4.1.2.1).
o REQ9: Specity the format of the identifiers of group members (see
Section 4.1.2.1).
o REQ10: Optionally, specify the format and content of
'group_policies' entries (see Section 4.1.2.1).
o REQ11: Specify the communication protocol the members of the group
must use (e.g., multicast CoAP).
o REQ12: Specify the security protocol the group members must use to
protect their communication (e.g., group OSCORE). This must protect their communication (e.g., group OSCORE). This must
provide encryption, integrity and replay protection. provide encryption, integrity and replay protection.
o Specify the encoding and value of the identifier of group or topic o REQ13: Specify and register the application profile identifier
and role of 'scope' (see Section 3.1). (see Section 4.1.2.1).
o Specify and register the application profile identifier (see
Section 4.1).
o Specify the acceptable values of 'kty' (see Section 4.2). o REQ14: Optionally, specify the encoding of public keys, of
'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
Section 4.1.2.1).
o Specify the format and content of 'group_policies' entries (see o REQ15: Specify policies at the KDC to handle id that are not
Section 4.2). included in get_pub_keys (see Section 4.1.3.1).
o Optionally, specify the format and content of 'mgt_key_material' o REQ16: Specify the format and content of 'group_policies' (see
(see Section 4.2). Section 4.1.2.1).
o Optionally, specify tranport profile of ACE o REQ17: Specify the format of newly-generated individual keying
[I-D.ietf-ace-oauth-authz] to use between Client and KDC. material for group members, or of the information to derive it,
and corresponding CBOR label (see Section 4.1.6.2).
o Optionally, specify the encoding of public keys, of 'client_cred', o REQ18: Specify how the communication is secured between Client and
and of 'pub_keys' if COSE_Keys are not used (see Section 4.2). KDC. Optionally, specify tranport profile of ACE
[I-D.ietf-ace-oauth-authz] to use between Client and KDC (see
Section 4.2.
o Optionally, specify the acceptable values for parameters related o OPT1: Optionally, specify the encoding of public keys, of
to signature algorithm and signature keys: 'sign_alg', 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
'sign_parameters', 'sign_key_parameters', 'pub_key_enc' (see Section 4.1.2.1).
Section 3.3).
o 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 format and content of
'mgt_key_material' (see Section 4.1.2.1).
o OPT4: Optionally, specify policies that instruct clients to retain
unsuccessfully decrypted messages and for how long, so that they
can be decrypted after getting updated keying material (OPT4).
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -01 to -02 B.1. Version -02 to -03
o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 3.3).
o Restructured KDC interface, with new possible operations
(Section 4).
o Client PoP signature for the Joining Request upon joining
(Section 4.1.2.1).
o Revised text on group member removal (Section 5).
o Added more profile requirements (Appendix A).
B.2. 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 34, line 48 skipping to change at page 40, line 18
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.2. Version -00 to -01 B.3. 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
skipping to change at page 35, line 37 skipping to change at page 41, line 7
o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm
Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence
Number Synchronization Method Registry" (Section 11). Number Synchronization Method Registry" (Section 11).
o Added appendix about requirements for application profiles of ACE o Added appendix about requirements for application profiles of ACE
on group communication (Appendix A). on group communication (Appendix A).
Acknowledgments Acknowledgments
The following individuals were helpful in shaping this document: Ben The following individuals were helpful in shaping this document:
Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel
Peter van der Stok. Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der
Stok.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
Initiative ACTIVE. Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
Kista SE-16440 Stockholm Kista SE-16440 Stockholm
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Marco Tiloca Marco Tiloca
RISE AB RISE AB
 End of changes. 182 change blocks. 
596 lines changed or deleted 881 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/