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/ |