draft-ietf-ace-key-groupcomm-03.txt   draft-ietf-ace-key-groupcomm-04.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: May 7, 2020 RISE AB Expires: July 18, 2020 RISE AB
November 04, 2019 January 15, 2020
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-03 draft-ietf-ace-key-groupcomm-04
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 May 7, 2020. This Internet-Draft will expire on July 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7
3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9
4. Keying Material Provisioning and Group Membership Management 11 4. Keying Material Provisioning and Group Membership Management 12
4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 12 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 13
4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 21 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 23
4.3. Retrieval of Updated Keying Material . . . . . . . . . . 22 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 24
4.4. Retrieval of New Keying Material . . . . . . . . . . . . 24 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 26
4.5. Retrieval of Public Keys for Group Members . . . . . . . 24 4.5. Retrieval of Public Keys for Group Members . . . . . . . 26
4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 25 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 27
4.7. Retrieval of Keying Material Version . . . . . . . . . . 25 4.7. Retrieval of Keying Material Version . . . . . . . . . . 27
4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 26 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 28
5. Removal of a Node from the Group . . . . . . . . . . . . . . 26 5. Removal of a Node from the Group . . . . . . . . . . . . . . 28
6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 27 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Update of Keying Material . . . . . . . . . . . . . . . . 29 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 31
7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 29 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. ACE Authorization Server Request Creation Hints Registry 30 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 32
8.2. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 30 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 33
8.3. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 31 8.3. ACE Authorization Server Request Creation Hints Registry 33
8.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 32 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 34
8.5. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 32 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 34
8.6. Sequence Number Synchronization Method Registry . . . . . 33 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 35
8.7. Expert Review Instructions . . . . . . . . . . . . . . . 34 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.8. Sequence Number Synchronization Method Registry . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 8.9. Expert Review Instructions . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Requirements on Application Profiles . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . 38
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 39 9.2. Informative References . . . . . . . . . . . . . . . . . 39
B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 39 Appendix A. Requirements on Application Profiles . . . . . . . . 41
B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 40 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 B.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 43
B.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 43
B.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
define the message exchanges used to request, distribute and renew define the message exchanges used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on the keying material in a group communication scenario, e.g. based on
multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- multicast [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, by Profiles that use group communication can build on this document, by
defining a number of details such as the exact group communication defining a number of details such as the exact group communication
protocol and security protocols used. The specific list of details a protocol and security protocols used. The specific list of details a
profile needs to define is in Appendix A. profile needs to define is shown in Appendix A.
If the application requires backward and forward security, updated If the application requires backward and forward security, 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. Rekeying remaining group members when a node leaves the group. Rekeying
mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627].
skipping to change at page 4, line 29 skipping to change at page 4, line 35
Figure 1: Key Distribution Participants Figure 1: Key Distribution Participants
The following participants (see Figure 1) take part in the The following participants (see Figure 1) take part in the
authorization and key distribution. authorization and key distribution.
o Client (C): node that wants to join the group communication. It o Client (C): node that wants to join the group communication. It
can request write and/or read rights. can request write and/or read rights.
o Authorization Server (AS): same as AS in the ACE Framework; it o Authorization Server (AS): same as AS in the ACE Framework; it
enforces access policies, and knows if a node is allowed to join enforces access policies, and knows if a node is allowed to join a
the group with write and/or read rights. given group with write and/or read rights.
o Key Distribution Center (KDC): maintains the keying material to o Key Distribution Center (KDC): maintains the keying material to
protect group communications, and provides it to Clients protect group communications, and provides it to Clients
authorized to join the group. During the first part of the authorized to join a given group. During the first part of the
exchange (Section 3), it takes the role of the RS in the ACE exchange (Section 3), it takes the role of the RS in the ACE
Framework. During the second part (Section 4), which is not based Framework. During the second part (Section 4), which is not based
on the ACE Framework, it distributes the keying material. In on the ACE Framework, it distributes the keying material. In
addition, it provides the latest keying material to group members addition, it provides the latest keying material to group members
when requested. If required by the application, the KDC renews when requested or, if required by the application, when membership
and re-distributes the keying material in the group when changes.
membership changes.
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.
skipping to change at page 5, line 19 skipping to change at page 5, line 24
o A node to leave the group of for the KDC to remove a current o A node to leave the group of for the KDC to remove a current
member of the group (Section 5). member of the group (Section 5).
o Retrieving keying material as a current group member (Section 4.3 o Retrieving keying material as a current group member (Section 4.3
and Section 4.4). and Section 4.4).
o Renewing and re-distributing the group keying material (rekeying) o Renewing and re-distributing the group keying material (rekeying)
upon a membership change in the group (Section 4.8 and Section 5). upon a membership change in the group (Section 4.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, which can be expanded as
follows.
1. The joining node requests an Access Token from the AS, in order
to access a specific group-membership resource on the KDC and
hence join the associated group. The joining node will start or
continue using a secure communication association with the KDC,
according to the response from the AS.
2. The joining node transfers authentication and authorization
information to the KDC, by posting the obtained Access Token to
the /authz-info endpoint at the KDC. After that, a joining node
MUST have a secure communication association established with the
KDC, before starting to join a group under that KDC. Possible
ways to provide a secure communication association are DTLS
[RFC6347] and OSCORE [RFC8613].
3. The joining node starts the joining process to become a member of
the group, by accessing the related group-membership resource at
the KDC. At the end of the joining process, the joining node has
received from the KDC the parameters and keying material to
securely communicate with the other members of the group.
4. The joining node and the KDC maintain the secure association, to
support possible future communications. These especially include
key management operations, such as retrieval of updated keying
material or participation to a group rekeying process.
C AS KDC Group C AS KDC Group
| | | Member | | | Member
/ | | | | / | | | |
| | Authorization Request | | | | | Authorization Request | | |
Defined | |---------------------------->| | | Defined | |---------------------------->| | |
in the | | | | | in the | | | | |
ACE | | Authorization Response | | | ACE | | Authorization Response | | |
framework | |<----------------------------| | | framework | |<----------------------------| | |
| | | | | | | |
skipping to change at page 9, line 40 skipping to change at page 10, line 22
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 The payload of the 2.01 response is a CBOR map, which MUST include
the parameter 'rsnonce' defined in Section Section 3.3.3, specifying the parameter 'rsnonce' defined in Section Section 3.3.3, specifying
a dedicated nonce N_S generated by the KDC. The Client may use this 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 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). Note that the payload
format of the response deviates from the default as defined in the
ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]).
Optionally, if they were included in the request, the AS MAY include Optionally, if they were included in the request, the KDC MAY include
the 'sign_info' parameter as well as the 'pub_key_enc' parameter the 'sign_info' parameter as well as the 'pub_key_enc' parameter
defined in Section 3.3.1 and Section 3.3.2 of this specification, defined in Section 3.3.1 and Section 3.3.2 of this specification,
respectively. respectively.
The 'sign_info' parameter MUST be present if the POST request The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter with value Null. If present, the included the 'sign_info' parameter with value Null. If present, the
'sign_info' parameter of the 2.01 (Created) response is a CBOR array 'sign_info' parameter of the 2.01 (Created) response is a CBOR array
formatted as follows. formatted as follows.
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,
skipping to change at page 10, line 27 skipping to change at page 11, line 9
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
(REQ5). If no parameters of the key used with the signature (REQ5). If no parameters of the key used with the signature
algorithm are specified, 'sign_key_parameters' MUST be encoded as algorithm are specified, 'sign_key_parameters' MUST be encoded as
the CBOR simple value Null. the CBOR simple value Null.
The 'pub_key_enc' parameter MUST be present if the POST request The 'pub_key_enc' parameter MUST be present if the POST request
included the 'pub_key_enc' parameter with value Null. If present, included the 'pub_key_enc' parameter with value Null. If present,
the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR the 'pub_key_enc' parameter of the 2.01 (Created) response is either
integer, indicating the encoding of public keys used in the group. a CBOR integer indicating the encoding of public keys used in the
group, or has value Null indicating that the KDC does not act as
repository of public keys for group members.
Its acceptable values are taken from the "CWT Confirmation Method" Its acceptable values are taken from the "CWT Confirmation Method"
Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is
REQUIRED of the application profiles to define specific values to use REQUIRED of the application profiles to define specific values to use
for this parameter (REQ6). for this parameter (REQ6).
The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters
formatted as in the response is given below. formatted as in the response is given below.
sign_info_res = [ sign_info_res = [
sign_alg : int / tstr, sign_alg : int / tstr,
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 / nil
Note that the CBOR map specified as payload of the 2.01 (Created) Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g. according to the response may include further parameters, e.g. according to the
signalled transport profile of ACE. signalled transport profile of ACE.
Applications of this specification MAY define alternative specific
negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2).
3.3.1. 'sign_info' Parameter 3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the 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, In this specification and in application profiles building on it,
skipping to change at page 12, line 7 skipping to change at page 12, line 42
This section defines the interface available at the KDC. Moreover, This section defines the interface available at the KDC. Moreover,
this section specifies how the clients can use this interface to join this section specifies how the clients can use this interface to join
a group, leave a group, retrieve new keying material or policies. a group, leave a group, retrieve new keying material or policies.
During the first exchange with the KDC ("Joining"), the Client sends During the first exchange with the KDC ("Joining"), the Client sends
a request to the KDC, specifying the group it wishes to join (see 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 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 is authorized to join that group. If so, it provides the
Client with the keying material to securely communicate with the Client with the keying material to securely communicate with the
other members of the group. Whenever used, the Content-Format in other members of the group. Whenever used, the Content-Format in
messages containing a payload is set to application/cbor. messages containing a payload is set to application/ace-
groupcomm+cbor, as defined in Section 8.2.
TODO: Do we need to define a new Content-Format cbor+ace-groupcomm?
When the Client is already a group member, the Client can use the When the Client is already a group member, the Client can use the
interface at the KDC to perform the following actions: interface at the KDC to perform the following actions:
o The Client can (re-)get the current keying material, for cases o The Client can (re-)get the current keying material, for cases
such as expiration, loss or suspected mismatch, due to e.g. reboot such as expiration, loss or suspected mismatch, due to e.g. reboot
or missed group rekeying. This is described in Section 4.3. or missed group rekeying. This is described in Section 4.3.
o The Client can retrieve a new individual key, or new input o The Client can retrieve a new individual key, or new input
material to derive it. This is described in Section 4.4. material to derive it. This is described in Section 4.4.
skipping to change at page 13, line 8 skipping to change at page 13, line 43
specification is used. Other applications that run on a KDC specification is used. Other applications that run on a KDC
implementing this specification MUST NOT use this same resource. implementing this specification MUST NOT use this same resource.
o /ace-group/gid : one sub-resource to /ace-group is implemented for o /ace-group/gid : one sub-resource to /ace-group is implemented for
each group the KDC manages. These resources are identified by the each group the KDC manages. These resources are identified by the
group identifiers of the groups the KDC manages (in this example, group identifiers of the groups the KDC manages (in this example,
the group identifier has value "gid"). These resources support the group identifier has value "gid"). These resources support
GET and POST method. GET and POST method.
o /ace-group/gid/pub-key : this sub-resource is fixed and supports o /ace-group/gid/pub-key : this sub-resource is fixed and supports
GET and POST methods. GET and FETCH methods.
o /ace-group/gid/policies: this sub-resource is fixed and supports o /ace-group/gid/policies: this sub-resource is fixed and supports
the GET method. the GET method.
o /ace-group/gid/ctx-num: this sub-resource is fixed and supports o /ace-group/gid/ctx-num: this sub-resource is fixed and supports
the GET method. the GET method.
o /ace-group/gid/node: this sub-resource is fixed and supports GET o /ace-group/gid/node: one sub-resource to /ace-group/gid is
and POST methods. implemented for each node in the group the KDC manages. These
resources are identified by the node name (in this example, the
node name has value "node"). These resources support GET, PUT and
DELETE methods.
The details for the handlers of each resource are given in the The details for the handlers of each resource are given in the
following sections. These endpoints are used to perform the following sections. These endpoints are used to perform the
operations introduced in Section 4. Note that the url-path given operations introduced in Section 4. Note that the url-path given
here are default names: implementations are not required to use these here are default names: implementations are not required to use these
names, and can define their own instead. names, and can define their own instead.
4.1.1. ace-group 4.1.1. ace-group
No handlers are implemented for this resource. No handlers are implemented for this resource.
skipping to change at page 14, line 8 skipping to change at page 14, line 45
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. This field contains the
(collecting from/distributing to the Client) the public keys of public key of the Client. This field is used if the KDC is
the group members, this field contains the public key of the managing (collecting from/distributing to the Client) the public
Client. The default encoding for public keys is COSE Keys. keys of the group members, and if the Client's role in the group
Alternative specific encodings of this parameter MAY be defined in will require for it to send messages to the group. The default
applications of this specification (OPT1). encoding for public keys is COSE Keys. Alternative specific
encodings of this parameter MAY be defined in applications of this
specification (OPT1).
o 'cnonce', as defined in Section 5.1.2 of o 'cnonce', as defined in Section 5.1.2 of
[I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C
generated by the Client. This parameter MUST be present if the generated by the Client. This parameter MUST be present if the
'client_cred' parameter is present. '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 MUST be present if the 'client_cred' parameter is parameter MUST be present if the 'client_cred' parameter is
present. This parameter contains a signature computed by the present. This parameter contains a signature computed by the
Client over N_S concatenated with N_C, where N_S is the nonce Client over N_S concatenated with N_C, where N_S is the nonce
received from the KDC in the 'rsnonce' parameter of the 2.01 received from the KDC in the 'rsnonce' parameter of the 2.01
(Created) response to the token POST request (see Section 3.3), (Created) response to the token POST request (see Section 3.3),
while N_C is the nonce generated by the Client and specified in while N_C is the nonce generated by the Client and specified in
the 'cnonce' parameter above. The Client computes the signature the 'cnonce' parameter above. If the token is not being posted
by using its own private key, whose corresponding public key is (e.g. if it is used directly to validate TLS instead), it is
either directly specified in the 'client_cred' parameter or REQUIRED of the specific profile to define how the nonce N_S is
included in the certificate specified in the 'client_cred' generated (REQ17). The Client computes the signature by using its
parameter. 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' parameter.
o 'pub_keys_repos', can be present if a certificate is present in o 'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value a list of public key the 'client_cred' field, with value the URI of the certificate of
repositories storing the certificate of the Client. This the Client. This parameter is encoded as a CBOR text string.
parameter is encoded as a CBOR array of CBOR text strings, each of Alternative specific encodings of this parameter MAY be defined in
which specifies the URI of a key repository. applications of this specification (OPT3).
The handler verifies that the group identifier of the /ace-group/gid 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 path is a subset of the 'scope' stored in the access token associated
to this client. If verification fails, the KDC MUST respond with a to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message. The KDC MAY set the payload with
the 'sign_info' and 'pub_key_enc' parameter, formatted as
'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01
(Created) response to the Token Post as defined in Section 3.3. Note
that in this case, the content format MUST be set to application/
ace+cbor.
If the request is not formatted correctly (e.g. unknown fields If the request is not formatted correctly (e.g. unknown, not-expected
present), the handler MUST respond with 4.00 (Bad Request) error fields present, or expected fields with incorrect format), the
handler MUST respond with 4.00 (Bad Request) error message. The
response MAY contain a CBOR map in the payload with ace-
groupcomm+cbor format, e.g. it could send back "pub_key_enc" set to
Null if the Client sent its own public key and the KDC is not set to
store public keys of the group members. Application profiles MAY
define optional or mandatory payload formats for specific error cases
(OPT6).
If the KDC stores the group members' public keys, the handler
verifies that one public key can be retrieved for the joining node,
either from the 'client_cred' field, or from the KDC previous
knowledge of it. In particular, the KDC checks that such public key
has an accepted format for the group identified by "gid", i.e. it is
encoded as expected and is compatible with the signature algorithm
and possible associated parameters. If that cannot be verified, it
is RECOMMENDED that the handler stops the joining process and
responds with 4.00 (Bad Request) error message. Applications
profiles MAY define alternatives (OPT5).
If the signature contained in "client_cred_verify" does not pass
verification, the handler MUST respond with 4.00 (Bad Request) error
message. message.
If verification succeeds, the handler adds the public key indicated If verification succeeds, the handler adds the retrieved public key
in "client_cred" to the list of public keys stored for the group of the joining node to the list of public keys stored for the group
identified by "gid". The handler returns a 2.01 (Created) message identified by "gid". Moreover, the handler assigns a name to the
containing the symmetric group keying material, the group policies node (e.g. "node1"), and creates a sub-resource to /ace-group/gid/ at
and all the public keys of the current members of the group, if the the KDC (e.g. "/ace-group/gid/node1"). The handler returns a 2.01
KDC manages those and the Client requested them. The payload of the (Created) message containing the symmetric group keying material, the
response is formatted as a CBOR map which MAY contain the following group policies and all the public keys of the current members of the
fields, which, if included, MUST have the corresponding values: group, if the KDC manages those and the Client requested them. The
response message also contains the URI path to the sub-resource
created for that node in a Location-Path CoAP option. 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 'gkty', identifying the key type of the 'key' parameter. The set
of values can be found in the "Key Type" column of the "ACE of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry. Implementations MUST verify that the key Groupcomm Key" Registry. Implementations MUST verify that the key
type matches the application profile being used, if present, as type matches the application profile being used, if present, as
registered in the "ACE Groupcomm Key" registry. registered in the "ACE Groupcomm Key" registry.
o 'key', containing the keying material for the group communication, o 'key', containing the keying material for the group communication,
or information required to derive it. or information required to derive it.
o 'num', containing the version number of the keying material for o 'num', containing the version number of the keying material for
the group communication, formatted as an integer. The initial the group communication, formatted as an integer. The initial
version MUST be set to 0 at the KDC. version MUST be set to 0 at the KDC. This is a strictly monotonic
increasing field.
The exact format of the 'key' value MUST be defined in applications The exact format of the 'key' value MUST be defined in applications
of this specification (REQ7), as well as accepted values of 'kty' by of this specification (REQ7), as well as accepted values of 'gkty' by
the application (REQ8). Additionally, documents specifying the key the application (REQ8). Additionally, documents specifying the key
format MUST register it in the "ACE Groupcomm Key" registry defined format MUST register it in the "ACE Groupcomm Key" registry defined
in Section 8.3, including its name, type and application profile to in Section 8.5, including its name, type and application profile to
be used with. be used with.
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Name | Key Type Value | Profile | Description | | Name | Key Type Value | Profile | Description |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Reserved | 0 | | This value is reserved | | Reserved | 0 | | This value is reserved |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
Figure 4: Key Type Values Figure 4: Key Type Values
Optionally, the response MAY contain the following parameters, which, Optionally, the response MAY contain the following parameters, which,
if included, MUST have the corresponding values: if included, MUST have the corresponding values:
o 'profile', with value a CBOR integer that MUST be used to uniquely o 'ace-groupcomm-profile', with value a CBOR integer that MUST be
identify the application profile for group communication. The used to uniquely identify the application profile for group
value MUST be registered in the "ACE Groupcomm Profile" Registry. communication. Applications of this specification MUST register
an application profile identifier and the related value for this
parameter in the "ACE Groupcomm Profile" Registry (REQ12).
o 'exp', with value the expiration time of the keying material for o 'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer or the group communication, encoded as a CBOR unsigned integer or
floating-point number. This field contains a numeric value floating-point number. This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds, until the specified UTC date/time, ignoring leap seconds,
analogous to what specified in Section 2 of [RFC7519]. analogous to what specified in Section 2 of [RFC7519].
o 'pub_keys', may only be present if 'get_pub_keys' was present in o 'pub_keys', may only be present if 'get_pub_keys' was present in
the request. This parameter is a CBOR byte string, which encodes the request. This parameter is a CBOR byte string, which encodes
the public keys of all the group members paired with the the public keys of all the group members paired with the
respective member identifiers. The default encoding for public respective member identifiers. The default encoding for public
keys is COSE Keys, so the default encoding for 'pub_keys' is a keys is COSE Keys, so the default encoding for 'pub_keys' is a
CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which
contains the public keys of all the members of the group. In contains the public keys of all the members of the group. In
particular, each COSE Key in the COSE_KeySet includes the particular, each COSE Key in the COSE_KeySet includes the
identifier of the corresponding group member as value of its 'kid' identifier of the corresponding group member as value of its 'kid'
key parameter. Alternative specific encodings of this parameter key parameter. Alternative specific encodings of this parameter
MAY be defined in applications of this specification (OPT2). The MAY be defined in applications of this specification (OPT1). The
specific format of the identifiers of group members MUST be specific format of the identifiers of group members MUST be
specified in the application profile (REQ8). specified in the application profile (REQ9).
o 'group_policies', with value a CBOR map, whose entries specify how o 'group_policies', with value a CBOR map, whose entries specify how
the group handles specific management aspects. These include, for the group handles specific management aspects. These include, for
instance, approaches to achieve synchronization of sequence instance, approaches to achieve synchronization of sequence
numbers among group members. The elements of this field are numbers among group members. The elements of this field are
registered in the "ACE Groupcomm Policy" Registry. This registered in the "ACE Groupcomm Policy" Registry. This
specification defines the two elements "Sequence Number specification defines the two elements "Sequence Number
Synchronization Method" and "Key Update Check Interval", which are Synchronization Method" and "Key Update Check Interval", which are
summarized in Figure 5. Application profiles that build on this summarized in Figure 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 (REQ9). entries (REQ14).
+-----------------+-------+----------|--------------------|------------+ +-----------------+-------+----------|--------------------|------------+
| Name | CBOR | CBOR | Description | Reference | | Name | CBOR | CBOR | Description | Reference |
| | label | type | | | | | label | type | | |
|-----------------+-------+----------|--------------------|------------| |-----------------+-------+----------|--------------------|------------|
| Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | | Sequence 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 17, line 32 skipping to change at page 18, line 35
| 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 5: 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 application profile MUST
depend on the specific rekeying scheme used in the group, which define if this field is used, and if used then MUST specify the
MAY be specified in the application profile (OPT3). exact format and content which depend on the specific rekeying
scheme used in the group. If the usage of 'mgt_key_material' is
indicated and its format defined for a specific key management
scheme, that format must explicitly indicate the key management
scheme itself. If a new rekeying scheme is defined to be used for
an existing 'mgt_key_material' in an existing profile, then that
profile will have to be updated accordingly, especially with
respect to the usage of 'mgt_key_material' related format and
content (REQ18).
Specific application profiles that build on this document MUST Specific application profiles that build on this document MUST
specify how exactly the keying material is used to protect the group specify the communication protocol that members of the group use to
communication (REQ10). communicate with each other (REQ10) and how exactly the keying
material is used to protect the group communication (REQ11).
CBOR labels for these fields are defined in Section 6. CBOR labels for these fields are defined in Section 6.
4.1.2.2. GET Handler 4.1.2.2. GET Handler
The GET handler returns the symmetric group keying material for the The GET handler returns the symmetric group keying material for the
group identified by "gid". group identified by "gid".
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/gid
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client. If verification fails, the KDC MUST respond with a to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message. The KDC MAY set the payload with
the 'sign_info' and 'pub_key_enc' parameter, formatted as
'sign_info_res' and 'pub_key_enc_res' in the payload of the 2.01
(Created) response to the Token Post as defined in Section 3.3. Note
that in this case, the content format MUST be set to application/
ace+cbor.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the symmetric group keying material, the group message containing the symmetric group keying material. The payload
policies and all the public keys of the current members of the group. of the response is formatted as a CBOR map which MUST contain the
The payload of the response is formatted as a CBOR map which MUST parameters 'gkty','key' and 'num' specified in Section 4.1.2.1.
contain the parameters 'kty','key' and 'num' specified in
Section 4.1.2.1.
The payload MAY also include the parameters 'profile', 'exp' and The payload MAY also include the parameters 'ace-groupcomm-profile',
'mgt_key_material' parameters specified in Section 4.1.2.1. 'exp' and 'mgt_key_material' parameters specified in Section 4.1.2.1.
4.1.3. ace-group/gid/pub-key 4.1.3. ace-group/gid/pub-key
This resource implements GET and POST handlers. This resource implements GET and FETCH handlers.
4.1.3.1. POST Handler 4.1.3.1. FETCH Handler
The POST handler receives identifiers of group members for the group The FETCH handler receives identifiers of group members for the group
identified by "gid" and returns the public keys of such group identified by "gid" and returns the public keys of such group
members. members.
The handler expects a request with payload formatted as a CBOR map. The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MUST contain the The payload of this request is a CBOR Map that MUST contain the
following fields: following fields:
o 'get_pub_keys', whose value is a non-empty CBOR array. Each o 'get_pub_keys', whose value is a non-empty CBOR array. Each
element of the array is the identifier of a group member for the element of the array is the identifier of a group member for the
group identified by "gid". The specific format of public keys as group identified by "gid". The specific format of public keys as
well as identifiers of group members MUST be specified by the well as identifiers of group members MUST be specified by the
application profile (REQ11, REQ8). application profile (OPT1, REQ9).
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/gid
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client. If verification fails, the KDC MUST respond with a to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
The handler verifies that the 'get_pub_keys' parameter is not an
empty CBOR Array. If verification fails, the KDC MUST treat the
request as malformed and respond with a 4.00 (Bad Request) error
message.
If verification succeeds, the handler identifies the public keys of If verification succeeds, the handler identifies the public keys of
the current group members for which the identifier matches with one the current group members for which the identifier matches with one
of those indicated in the request. Then, the handler returns a 2.05 of those indicated in the request. Then, the handler returns a 2.05
(Content) message response with payload formatted as a CBOR map (Content) message response with payload formatted as a CBOR map
containing only the 'pub_keys' parameter from Section 4.1.2.1, which containing only the 'pub_keys' parameter from Section 4.1.2.1, which
encodes the list of public keys of those group members including the encodes the list of public keys of those group members including the
respective member identifiers. If the KDC does not store any public respective member identifiers. If the KDC does not store any public
key associated with the specified member identifiers, the handler key associated with the specified member identifiers, the handler
returns a response with payload formatted as a CBOR byte string of returns a response with payload formatted as a CBOR byte string of
zero length. The specific format of public keys as well as of zero length. The specific format of public keys as well as of
identifiers of group members is specified by the application profile identifiers of group members is specified by the application profile
(REQ11, REQ8). (OPT1, REQ9).
The handler MAY enforce one of the following policies, in order to The handler MAY enforce one of the following policies, in order to
handle possible identifiers that are included in the 'get_pub_keys' handle possible identifiers that are included in the 'get_pub_keys'
parameter of the request but are not associated to any current group parameter of the request but are not associated to any current group
member. Such a policy MUST be specified by the application profile member. Such a policy MUST be specified by the application profile
(REQ12) (REQ13)
o The KDC silently ignores those identifiers. o The KDC silently ignores those identifiers.
o The KDC retains public keys of group members for a given amount of o The KDC retains public keys of group members for a given amount of
time after their leaving, before discarding them. As long as such time after their leaving, before discarding them. As long as such
public keys are retained, the KDC provides them to a requesting public keys are retained, the KDC provides them to a requesting
Client. Client.
4.1.3.2. GET Handler 4.1.3.2. GET Handler
skipping to change at page 19, line 40 skipping to change at page 21, line 5
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the public keys of all the current group members, message containing the public keys of all the current group members,
for the group identified by "gid". The payload of the response is for the group identified by "gid". The payload of the response is
formatted as a CBOR map containing only the 'pub_keys' parameter from 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 Section 4.1.2.1, which encodes the list of public keys of all the
group members including the respective member identifiers. If the group members including the respective member identifiers. If the
KDC does not store any public key for the group, the handler returns 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 a response with payload formatted as a CBOR byte string of zero
length. The specific format of public keys as well as of identifiers length. The specific format of public keys as well as of identifiers
of group members is specified by the application profile (REQ11, of group members is specified by the application profile (OPT1,
REQ8). REQ9).
4.1.4. ace-group/gid/policies 4.1.4. ace-group/gid/policies
This resource implements a GET handler. This resource implements a GET handler.
4.1.4.1. GET Handler 4.1.4.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/gid
skipping to change at page 20, line 19 skipping to change at page 21, line 30
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the list of policies for the group identified by message containing the list of policies for the group identified by
"gid". The payload of the response is formatted as a CBOR map "gid". The payload of the response is formatted as a CBOR map
including only the parameter 'group_policies' defined in including only the parameter 'group_policies' defined in
Section 4.1.2.1 and specifying the current policies in the group. If Section 4.1.2.1 and specifying the current policies in the group. If
the KDC does not store any policy, the payload is formatted as a the KDC does not store any policy, the payload is formatted as a
zero-length CBOR byte string. zero-length CBOR byte string.
The specific format and meaning of group policies MUST be specified The specific format and meaning of group policies MUST be specified
in the application profile (REQ13). in the application profile (REQ14).
4.1.5. ace-group/gid/ctx-num 4.1.5. ace-group/gid/ctx-num
This resource implements a GET handler. This resource implements a GET handler.
4.1.5.1. GET Handler 4.1.5.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/gid
skipping to change at page 20, line 43 skipping to change at page 22, line 7
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing an integer that represents the version number of message containing an integer that represents the version number of
the symmetric group keying material. This number is incremented on the symmetric group keying material. This number is incremented on
the KDC every time the KDC updates the symmetric group keying the KDC every time the KDC updates the symmetric group keying
material. The payload of the response is formatted as a CBOR material. The payload of the response is formatted as a CBOR
integer. integer.
4.1.6. ace-group/gid/node 4.1.6. ace-group/gid/node
This resource implements GET and POST handlers. This resource implements GET, PUT and DELETE handlers.
4.1.6.1. POST Handler 4.1.6.1. PUT Handler
The POST handler removes the node from the group, for the group The PUT handler is used to get the KDC to produce and return
identified by "gid". individual keying material to protect outgoing messages for the node
(identified by "node") for the group identified by "gid".
The handler expects a request with empty payload.
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 (REQ15) and registered in
Section 8.4.
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, identified by "node". 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 both the group keying material and the 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 format for the group keying material is the same as defined in
the response of Section 4.1.2.2. The specific format of individual
keying material for group members, or of the information to derive
it, and corresponding CBOR label, MUST be specified in the
application profile (REQ15) and registered in Section 8.4.
4.1.6.3. DELETE Handler
The DELETE handler removes the node (identified by "node") from the
group, for the group identified by "gid". If the node sending the
request and the node name used in the Uri-Path do not match, the
handler responds with a 4.01 (Unauthorized) error response.
TODO: Check the previous sentence.
The handler expects a request with payload formatted as a CBOR map. The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MAY contain only the The payload of this request is a CBOR Map that MAY contain only the
'scope' field as specified in Section 4.1.2.1. 'scope' field as specified in Section 4.1.2.1.
The handler verifies that the group identifier of the /ace-group/gid The handler verifies that the group identifier of the /ace-group/gid
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client. If verification fails, the KDC MUST respond with a to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
If the request contained a 'scope' field, the handler MUST extract If the request contained a 'scope' field, the handler MUST extract
the roles for that client. If the value is such that the KDC cannot the roles for that client. If the value is such that the KDC cannot
extract all the necessary information to understand and process it extract all the necessary information to understand and process it
correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00 correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00
(Bad Request) error message. (Bad Request) error message.
If verification succeeds, the handler removes the client from the If verification succeeds, the handler removes the client from the
group identified by "gid", for specific roles if roles were specified group identified by "gid", for specific roles if roles were specified
in the 'scope' field, or for all roles. That includes removing the 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 public key of the client if the KDC keep tracks of that. Then, the
handler returns a 2.05 (Content) message with empty payload. handler delete the sub-resource /node and returns a 2.02 (Deleted)
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 4.2. Joining Exchange
Figure 6 gives an overview of the Joining exchange between Client and Figure 6 gives an overview of the Joining exchange between Client and
KDC, when the Client first joins a group. KDC, when the Client first joins a group.
Client KDC Client KDC
| | | |
|-------- Joining Request: POST /ace-group/gid --------->| |-------- Joining Request: POST /ace-group/gid --------->|
| | | |
|<--------- Joining Response: 2.01 (Created) ----------- | |<--------- Joining Response: 2.01 (Created) ----------- |
| | | Location-Path = "/ace-group/gid/node" |
Figure 6: Message Flow of First Exchange for Group Joining Figure 6: Message Flow of First Exchange for Group Joining
If not previously established, the Client and the KDC MUST first If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel (REQ15). This can establish a pairwise secure communication channel (REQ16). This can
be achieved, for instance, by using a transport profile of ACE. The be achieved, for instance, by using a transport profile of ACE. The
Joining exchange MUST occur over that secure channel. The Client and Joining exchange MUST occur over that secure channel. The Client and
the KDC MAY use that same secure channel to protect further pairwise the KDC MAY use that same secure channel to protect further pairwise
communications that must be secured. communications that must be secured.
The secure communication protocol is REQUIRED to establish the secure The secure communication protocol is REQUIRED to establish the secure
channel by using the proof-of-possession key bound to the access channel by using the proof-of-possession key bound to the access
token. As a result, the proof-of-possession to bind the access token token. As a result, the proof-of-possession to bind the access token
to the Client is performed by using the proof-of-possession key bound to the Client is performed by using the proof-of-possession key bound
to the access token for establishing secure communication between the to the access token for establishing secure communication between the
Client and the KDC. Client and the KDC.
To join the group, the Client sends a CoAP POST request to the /ace- To join the group, the Client sends a CoAP POST request to the /ace-
group/gid endpoint at the KDC, where gid is the group identifier of group/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 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 group identifier is the same as the 'scope' value of the
Authorization Request/Response, or it can be retrieved from it. Authorization Request/Response, or it can be retrieved from it. Note
that, in case of successful joining, the Client will receive the URI
to retrieve individual or group keying material and to leave the
group in the Location-Path option of the response.
If the application requires backward security, the KDC MUST generate If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the new group keying material and securely distribute it to all the
current group members, upon a new node's joining the group. To this current group members, upon a new node's joining the group. To this
end, the KDC uses the message format of the Joining Response (see end, the KDC uses the message format of the Joining Response (see
Section 4.1.2.1). Application profiles may define alternative ways Section 4.1.2.1). Application profiles may define alternative ways
of retrieving the keying material, such as sending separate requests of retrieving the keying material, such as sending separate requests
to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2,
Section 4.1.4.1). After distributing the new group keying material, Section 4.1.4.1). After distributing the new group keying material,
the KDC MUST increment the version number of the keying material. the KDC MUST increment the version number of the keying material.
skipping to change at page 22, line 49 skipping to change at page 24, line 48
Joining response, or to a pre-configured value. Then, if it wants to Joining response, or to a pre-configured value. Then, if it wants to
continue participating in the group communication, the node has to continue participating in the group communication, the node has to
request new updated keying material from the KDC. request new updated keying material from the KDC.
The Client may need to request the latest group keying material also The Client may need to request the latest group keying material also
upon receiving messages from other group members without being able upon receiving messages from other group members without being able
to retrieve the material to correctly decrypt them. This may be due to retrieve the material to correctly decrypt them. This may be due
to a previous update of the group keying material (rekeying) to a previous update of the group keying material (rekeying)
triggered by the KDC, that the Client was not able to receive or 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 decrypt. To this end, the Client sends a CoAP GET request to the
/ace-group/gid endpoint at the KDC, formatted as specified in /ace-group/gid/node endpoint at the KDC, formatted as specified in
Section 4.1.2.2. Section 4.1.6.2.
Note that policies can be set up so that the Client sends a Key Re- Note that policies can be set up so that the Client sends a Key Re-
Distribution Request to the KDC only after a given number of Distribution Request to the KDC only after a given number of
unsuccessfully decrypted incoming messages. It is application unsuccessfully decrypted incoming messages. It is application
dependent and pertaining to the particular message exchange (e.g. dependent and pertaining to the particular message exchange (e.g.
[I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct
clients to retain unsuccessfully decrypted messages and for how long, clients to retain unsuccessfully decrypted messages and for how long,
so that they can be decrypted after getting updated keying material, so that they can be decrypted after getting updated keying material,
rather than just considered non valid messages to discard right away rather than just considered non valid messages to discard right away
(OPT4). (OPT4).
skipping to change at page 23, line 25 skipping to change at page 25, line 25
The same Key Distribution Request could also be sent by the Client The same Key Distribution Request could also be sent by the Client
without being triggered by a failed decryption of a message, if the without being triggered by a failed decryption of a message, if the
Client wants to be sure that it has the latest group keying material. Client wants to be sure that it has the latest group keying material.
If that is the case, the Client will receive from the KDC the same If that is the case, the Client will receive from the KDC the same
group keying material it already has in memory. group keying material it already has in memory.
Figure 7 gives an overview of the exchange described above. Figure 7 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|----- Key Distribution Request: GET ace-group/gid ----->| |--- Key Distribution Request: GET ace-group/gid/node -->|
| | | |
|<----- Key Distribution Response: 2.05 (Content) -------| |<----- Key Distribution Response: 2.05 (Content) -------|
| | | |
Figure 7: Message Flow of Key Distribution Request-Response 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 make the ace-group/gid resource Observable, and send o Can make the ace-group/gid/node resource Observable, and send
notifications to Clients when the keying material is updated. notifications to Clients when the keying material is updated.
o Can send the Key Distribution Response as one or multiple o Can send the Key Distribution Response as one or multiple
multicast requests to the members of the group, using secure multicast requests to the members of the group, using 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 same payload as the Key Distribution Response. 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
skipping to change at page 24, line 14 skipping to change at page 26, line 14
4.4. Retrieval of New Keying Material 4.4. Retrieval of New Keying Material
Beside possible expiration and depending on what part of the keying Beside possible expiration and depending on what part of the keying
material is no longer eligible to be used, the client may need to material is no longer eligible to be used, the client may need to
communicate to the KDC its need for that part to be renewed. For communicate to the KDC its need for that part to be renewed. For
example, if the Client uses an individual key to protect outgoing example, if the Client uses an individual key to protect outgoing
traffic and has to renew it, the node may request a new one, or new traffic and has to renew it, the node may request a new one, or new
input material to derive it, without renewing the whole group keying input material to derive it, without renewing the whole group keying
material. To this end, the client performs a Key Renewal Request/ material. To this end, the client performs a Key Renewal Request/
Response exchange with the KDC, that is a CoAP GET request to the Response exchange with the KDC, that is a CoAP PUT request to the
/ace-group/gid/node endpoint at the KDC, where gid is the group /ace-group/gid/node endpoint at the KDC, where gid is the group
identifier, and formatted as defined in Section 4.1.6.2. identifier and node the node's name, and formatted as defined in
Section 4.1.6.2.
Figure 8 gives an overview of the exchange described above. Figure 8 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|---- Key Renewal Request: GET ace-group/gid/node --->| |---- Key Renewal Request: PUT ace-group/gid/node --->|
| | | |
|<----- Key Renewal Response: 2.05 (Content) ---------| |<----- Key Renewal Response: 2.05 (Content) ---------|
| | | |
Figure 8: Message Flow of Key Renewal Request-Response Figure 8: Message Flow of Key Renewal Request-Response
Note the difference between the Key Distribution Request and the Key Note the difference between the Key Distribution Request and the Key
Renewal Request: while the first one only triggers distribution (the Renewal Request: while the first one only triggers distribution (the
renewal might have happened independently, e.g. because of renewal might have happened independently, e.g. because of
expiration), the second one triggers the KDC to produce new expiration), the second one triggers the KDC to produce new
individual keying material for the requesting node. individual keying material for the requesting node.
4.5. Retrieval of Public Keys for Group Members 4.5. Retrieval of Public Keys for Group Members
In case the KDC maintains the public keys of group members, a node in In case the KDC maintains the public keys of group members, a node in
the group can contact the KDC to request public keys of either all the group can contact the KDC to request public keys of either all
group members or a specified subset, by sending a CoAP GET or POST group members or a specified subset, by sending a CoAP GET or FETCH
request to the /ace-group/gid/pub-key endpoint at the KDC, where gid request to the /ace-group/gid/pub-key endpoint at the KDC, where gid
is the group identifier, and formatted as defined in Section 4.1.3.2 is the group identifier, and formatted as defined in Section 4.1.3.2
and Section 4.1.3.1. and Section 4.1.3.1.
Figure 9 and Figure 10 give an overview of the exchanges described Figure 9 and Figure 10 give an overview of the exchanges described
above. above.
Client KDC Client KDC
| | | |
|---- Public Key Request: GET /ace-group/gid/pub-key --->| |---- Public Key Request: GET /ace-group/gid/pub-key --->|
| | | |
|<--------- Public Key Response: 2.05 (Content) ---------| |<--------- Public Key Response: 2.05 (Content) ---------|
| | | |
Figure 9: Message Flow of Public Key Exchange to Request All Members Figure 9: Message Flow of Public Key Exchange to Request All Members
Public Keys Public Keys
Client KDC Client KDC
| | | |
|--- Public Key Request: POST /ace-group/gid/pub-key --->| |--- Public Key Request: FETCH /ace-group/gid/pub-key --->|
| | | |
|<--------- Public Key Response: 2.01 (Created) ---------| |<--------- Public Key Response: 2.01 (Created) ---------|
| | | |
Figure 10: Message Flow of Public Key Exchange to Request Specific Figure 10: Message Flow of Public Key Exchange to Request Specific
Members Public Keys Members Public Keys
4.6. Retrieval of Group Policies 4.6. Retrieval of Group Policies
A node in the group can contact the KDC to retrieve the current group A node in the group can contact the KDC to retrieve the current group
skipping to change at page 26, line 17 skipping to change at page 28, line 17
|----- Version Request: GET ace-group/gid/ctx-num ----->| |----- Version Request: GET ace-group/gid/ctx-num ----->|
| | | |
|<--------- Version Response: 2.05 (Content) -----------| |<--------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 12: Message Flow of Version Request-Response Figure 12: Message Flow of Version Request-Response
4.8. Group Leaving Request 4.8. Group Leaving Request
A node can actively request to leave the group. In this case, the A node can actively request to leave the group. In this case, the
Client sends a CoAP POST request to the endpoint /ace-group/gid/node Client sends a CoAP DELETE request to the endpoint /ace-group/gid/
at the KDC, where gid is the group identifier, formatted as defined node at the KDC, where gid is the group identifier and node the
in Section 4.1.6.1 node's name, formatted as defined in Section 4.1.6.3
Alternatively, a node may be removed by the KDC, without having Alternatively, a node may be removed by the KDC, without having
explicitly asked for it. This is further discussed in Section 5. explicitly asked for it. This is further discussed in Section 5.
5. Removal of a Node from the Group 5. Removal of a Node from the Group
This section describes the different scenarios according to which a This section describes the different scenarios according to which a
node ends up being removed from the group. node ends up being removed from the group.
If the application requires forward security, the KDC MUST generate If the application requires forward security, the KDC MUST generate
skipping to change at page 27, line 23 skipping to change at page 29, line 23
Either case, once aware that a node is not authorized anymore, Either case, once aware that a node is not authorized anymore,
the KDC has to remove the unauthorized node from the list of the KDC has to remove the unauthorized node from the list of
group members, if the KDC keeps track of that. group members, if the KDC keeps track of that.
6. ACE Groupcomm Parameters 6. ACE Groupcomm Parameters
This specification defines a number of fields used during the second This specification defines a number of fields used during the second
part of the message exchange, after the ACE Token POST exchange. The part of the message exchange, after the ACE Token POST exchange. The
table below summarizes them, and specifies the CBOR key to use table below summarizes them, and specifies the CBOR key to use
instead of the full descriptive name. instead of the full descriptive name. Note that the media type ace-
groupcomm+cbor MUST be used when these fields are transported.
+--------------------+--------+-----------------------+-------------+ +-----------------------+--------+---------------------+------------+
| Name | CBOR | CBOR Type | Reference | | Name | CBOR | CBOR Type | Reference |
| | Key | | | | | Key | | |
+--------------------+--------+-----------------------+-------------+ +-----------------------+--------+---------------------+------------+
| scope | TBD | array | Section | | scope | TBD | array | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| get_pub_keys | TBD | array | Section | | get_pub_keys | TBD | array | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| client_cred | TBD | byte string | Section | | client_cred | TBD | byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| cnonce | TBD | byte string | Section | | cnonce | TBD | byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| client_cred_verify | TBD | byte string | Section | | client_cred_verify | TBD | byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| pub_keys_repos | TBD | array | Section | | pub_keys_repos | TBD | array | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| kty | TBD | int / byte string | Section | | gkty | TBD | int / byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| key | TBD | see "ACE Groupcomm | Section | | key | TBD | see "ACE Groupcomm | Section |
| | | Key" Registry | 4.1.2.1 | | | | Key" Registry | 4.1.2.1 |
| | | | | | | | | |
| num | TBD | int | Section | | num | TBD | int | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| profile | TBD | int | Section | | ace-groupcomm-profile | TBD | int | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| exp | TBD | int / float | Section | | exp | TBD | int / float | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| pub_keys | TBD | byte string | Section | | pub_keys | TBD | byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| group_policies | TBD | map | Section | | group_policies | TBD | map | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| mgt_key_material | TBD | byte string | Section | | mgt_key_material | TBD | byte string | Section |
| | | | 4.1.2.1 | | | | | 4.1.2.1 |
| | | | | | | | | |
| get_pub_keys | TBD | array | Section | | get_pub_keys | TBD | array | Section |
| | | | 4.1.3.1 | | | | | 4.1.3.1 |
+--------------------+--------+-----------------------+-------------+ +-----------------------+--------+---------------------+------------+
7. Security Considerations 7. Security Considerations
When a Client receives a message from a sender for the first time, it When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g. needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of [RFC8613]. Appendix B.2 of [RFC8613].
The KDC must renew the group keying material upon its expiration. The KDC must renew the group keying material upon its expiration.
The KDC should renew the keying material upon group membership The KDC should renew the keying material upon group membership
skipping to change at page 30, line 17 skipping to change at page 32, line 18
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 bandwidth resending the blocks consume a larger amount of the network bandwidth resending the blocks
again and again, which might be problematic. again and again, which might be problematic.
8. IANA Considerations 8. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
8.1. ACE Authorization Server Request Creation Hints Registry 8.1. Media Type Registrations
This specification registers the 'application/ace-groupcomm+cbor'
media type for messages of the protocols defined in this document
following the ACE exchange and carrying parameters encoded in CBOR.
This registration follows the procedures specified in [RFC6838].
Type name: application
Subtype name: ace-groupcomm+cbor
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as CBOR map containing the
protocol parameters defined in [this document].
Security considerations: See Section 7 of this document.
Interoperability considerations: n/a
Published specification: [this document]
Applications that use this media type: The type is used by
authorization servers, clients and resource servers that support the
ACE groupcomm framework as specified in [this document].
Additional information:
Magic number(s): n/a
File extension(s): .ace-groupcomm
Macintosh file type code(s): n/a
Person & email address to contact for further information:
iesg@ietf.org [1]
Intended usage: COMMON
Restrictions on usage: None
Author: Francesca Palombini francesca.palombini@ericsson.com [2]
Change controller: IESG
8.2. CoAP Content-Formats Registry
This specification registers the following entry to the "CoAP
Content-Formats" registry, within the "CoRE Parameters" registry:
Media Type: application/ace-groupcomm+cbor
Encoding: -
ID: TBD
Reference: [this document]
8.3. 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 30, line 38 skipping to change at page 34, line 4
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]]
o Name: rsnonce o Name: rsnonce
o CBOR Key: TBD (range -256 to 255) o CBOR Key: TBD (range -256 to 255)
o Value Type: byte string o Value Type: byte string
o Reference: [[This specification]] o Reference: [[This specification]]
8.2. ACE Groupcomm Parameters Registry 8.4. 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 8.7. are provided in Section 8.9.
The columns of this Registry are: The columns of this Registry are:
o Name: This is a descriptive name that enables easier reference to o Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o 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.
skipping to change at page 31, line 28 skipping to change at page 34, line 40
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 item. the item.
This Registry has been initially populated by the values in This Registry has been initially populated by the values in
Section 6. The Reference column for all of these entries refers to Section 6. The Reference column for all of these entries refers to
sections of this document. sections of this document.
8.3. ACE Groupcomm Key Registry 8.5. 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 8.7. provided in Section 8.9.
The columns of this Registry are: The columns of this Registry are:
o Name: This is a descriptive name that enables easier reference to o Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o Key Type Value: This is the value used to identify the keying o Key Type Value: This is the value used to identify the keying
material. These values MUST be unique. The value can be a material. These values MUST be unique. The value can be a
positive integer, a negative integer, or a string. positive integer, a negative integer, or a string.
skipping to change at page 32, line 12 skipping to change at page 35, line 24
o Description: This field contains a brief description of the keying o Description: This field contains a brief description of the keying
material. material.
o References: This contains a pointer to the public specification o References: This contains a pointer to the public specification
for the format of the keying material, if one exists. for the format of the keying material, if one exists.
This Registry has been initially populated by the values in Figure 4. This Registry has been initially populated by the values in Figure 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.
8.4. ACE Groupcomm Profile Registry 8.6. ACE Groupcomm Profile Registry
This specification establishes the "ACE Groupcomm Profile" IANA This specification establishes the "ACE Groupcomm Profile" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 8.7. It should be noted that, in addition to are provided in Section 8.9. It should be noted that, in addition to
the expert review, some portions of the Registry require a the expert review, some portions of the Registry require a
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
skipping to change at page 32, line 42 skipping to change at page 36, line 5
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.
8.5. ACE Groupcomm Policy Registry 8.7. 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 8.7. It should be noted that, in addition to are provided in Section 8.9. It should be noted that, in addition to
the expert review, some portions of the Registry require a the expert review, some portions of the Registry require a
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
skipping to change at page 33, line 29 skipping to change at page 36, line 41
o Description: This field contains a brief description for this o Description: This field contains a brief description for this
group communication policy. group communication policy.
o Reference: This field contains a pointer to the public o Reference: This field contains a pointer to the public
specification providing the format of the group communication specification providing the format of the group communication
policy, if one exists. policy, if one exists.
This registry will be initially populated by the values in Figure 5. This registry will be initially populated by the values in Figure 5.
8.6. Sequence Number Synchronization Method Registry 8.8. Sequence Number Synchronization Method Registry
This specification establishes the "Sequence Number Synchronization This specification establishes the "Sequence Number Synchronization
Method" IANA Registry. The Registry has been created to use the Method" IANA Registry. The Registry has been created to use the
"Expert Review Required" registration procedure [RFC8126]. Expert "Expert Review Required" registration procedure [RFC8126]. Expert
review guidelines are provided in Section 8.7. It should be noted review guidelines are provided in Section 8.9. It should be noted
that, in addition to the expert review, some portions of the Registry that, in addition to the expert review, some portions of the Registry
require a specification, potentially a Standards Track RFC, be require a specification, potentially a Standards Track RFC, be
supplied as well. supplied as well.
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.
8.7. Expert Review Instructions 8.9. 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 35, line 9 skipping to change at page 38, line 19
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29
(work in progress), October 2019. (work in progress), December 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-11 (work in progress), January 2020.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-05 (work in progress), draft-ietf-core-oscore-groupcomm-06 (work in progress),
July 2019. November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[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)",
skipping to change at page 35, line 50 skipping to change at page 39, line 18
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.dijk-core-groupcomm-bis] [I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-01 (work in progress), July 2019. dijk-core-groupcomm-bis-02 (work in progress), November
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-09 (work in progress), December 2019.
[I-D.ietf-ace-mqtt-tls-profile] [I-D.ietf-ace-mqtt-tls-profile]
Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
of ACE", draft-ietf-ace-mqtt-tls-profile-01 (work in of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in
progress), October 2019. progress), December 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-08 (work in progress), July 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
skipping to change at page 36, line 44 skipping to change at page 40, line 15
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997, DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>. <https://www.rfc-editor.org/info/rfc2094>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999, DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>. <https://www.rfc-editor.org/info/rfc2627>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
skipping to change at page 37, line 20 skipping to change at page 40, line 43
[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, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
Appendix A. Requirements on Application Profiles 9.3. URIs
TODO: fix req numbers in the text. [1] mailto:iesg@ietf.org
[2] mailto:francesca.palombini@ericsson.com
Appendix A. Requirements on Application Profiles
This section lists the requirements on application profiles of this This section lists the requirements on application profiles of this
specification,for the convenience of application profile designers. specification,for the convenience of application profile designers.
o REQ1: Specify the encoding and value of the identifier of group or o REQ1: Specify the encoding and value of the identifier of group or
topic of 'scope' (see Section 3.1). topic of 'scope' (see Section 3.1).
o REQ2: Specify the encoding and value of roles of 'scope' (see o REQ2: Specify the encoding and value of roles of 'scope' (see
Section 3.1). Section 3.1).
o REQ3: Optionally, specify the acceptable values for 'sign_alg' o REQ3: If used, specify the acceptable values for 'sign_alg' (see
(see Section 3.3). Section 3.3).
o REQ4: Optionally, specify the acceptable values for o REQ4: If used, specify the acceptable values for 'sign_parameters'
'sign_parameters' (see Section 3.3). (see Section 3.3).
o REQ5: Optionally, specify the acceptable values for o REQ5: If used, specify the acceptable values for
'sign_key_parameters' (see Section 3.3). 'sign_key_parameters' (see Section 3.3).
o REQ6: Optionally, specify the acceptable values for 'pub_key_enc' o REQ6: If used, specify the acceptable values for 'pub_key_enc'
(see Section 3.3). (see Section 3.3).
o REQ7: Specify the exact format of the 'key' value (see o REQ7: Specify the exact format of the 'key' value (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ8: Specify the acceptable values of 'kty' (see o REQ8: Specify the acceptable values of 'gkty' (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ9: Specity the format of the identifiers of group members (see o REQ9: Specify the format of the identifiers of group members (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ10: Optionally, specify the format and content of o REQ10: Specify the communication protocol the members of the group
'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). must use (e.g., multicast CoAP).
o REQ12: Specify the security protocol the group members must use to o REQ11: 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 REQ13: Specify and register the application profile identifier o REQ12: Specify and register the application profile identifier
(see Section 4.1.2.1). (see Section 4.1.2.1).
o REQ14: Optionally, specify the encoding of public keys, of o REQ13: Specify policies at the KDC to handle ids that are not
'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
Section 4.1.2.1).
o REQ15: Specify policies at the KDC to handle id that are not
included in get_pub_keys (see Section 4.1.3.1). included in get_pub_keys (see Section 4.1.3.1).
o REQ16: Specify the format and content of 'group_policies' (see o REQ14: If used, specify the format and content of 'group_policies'
Section 4.1.2.1). and its entries (see Section 4.1.2.1).
o REQ17: Specify the format of newly-generated individual keying o REQ15: Specify the format of newly-generated individual keying
material for group members, or of the information to derive it, material for group members, or of the information to derive it,
and corresponding CBOR label (see Section 4.1.6.2). and corresponding CBOR label (see Section 4.1.6.2).
o REQ18: Specify how the communication is secured between Client and o REQ16: Specify how the communication is secured between Client and
KDC. Optionally, specify tranport profile of ACE KDC. Optionally, specify tranport profile of ACE
[I-D.ietf-ace-oauth-authz] to use between Client and KDC (see [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see
Section 4.2. Section 4.2.
o REQ17: Specify how the nonce N_S is generated, if the token is not
being posted (e.g. if it is used directly to validate TLS
instead).
o REQ18: Specify if 'mgt_key_material' used, and if yes specify its
format and content (see Section 4.1.2.1). If the usage of
'mgt_key_material' is indicated and its format defined for a
specific key management scheme, that format must explicitly
indicate the key management scheme itself. If a new rekeying
scheme is defined to be used for an existing 'mgt_key_material' in
an existing profile, then that profile will have to be updated
accordingly, especially with respect to the usage of
'mgt_key_material' related format and content.
o OPT1: Optionally, specify the encoding of public keys, of o OPT1: Optionally, specify the encoding of public keys, of
'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
Section 4.1.2.1). Section 4.1.2.1).
o OPT2: Optionally, specify the negotiation of parameter values for o OPT2: Optionally, specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' and signature algorithm and signature keys, if 'sign_info' and
'pub_key_enc' are not used (see Section 3.3). 'pub_key_enc' are not used (see Section 3.3).
o OPT3: Optionally, specify the format and content of o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the
'mgt_key_material' (see Section 4.1.2.1). default is not used (see Section 4.1.2.1).
o OPT4: Optionally, specify policies that instruct clients to retain o OPT4: Optionally, specify policies that instruct clients to retain
unsuccessfully decrypted messages and for how long, so that they unsuccessfully decrypted messages and for how long, so that they
can be decrypted after getting updated keying material (OPT4). can be decrypted after getting updated keying material.
o OPT5: Optionally, specify the behavior of the handler in case of
failure to retrieve a public key for the specific node (see
Section 4.1.2.1).
o OPT6: Optionally, specify possible or required payload formats for
specific error cases.
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -02 to -03 B.1. Version -03 to -04
o Revised RESTful interface, as to methods and parameters.
o Extended processing of joining request, as to check/retrieval of
public keys.
o Revised and extended profile requirements.
o Clarified specific usage of parameters related to signature
algorithms/keys.
o Included general content previously in draft-ietf-ace-key-
groupcomm-oscore
o Registration of media type and content format application/ace-
group+cbor
o Editorial improvements.
B.2. Version -02 to -03
o Exchange of information on the countersignature algorithm and o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 3.3). related parameters, during the Token POST (Section 3.3).
o Restructured KDC interface, with new possible operations o Restructured KDC interface, with new possible operations
(Section 4). (Section 4).
o Client PoP signature for the Joining Request upon joining o Client PoP signature for the Joining Request upon joining
(Section 4.1.2.1). (Section 4.1.2.1).
o Revised text on group member removal (Section 5). o Revised text on group member removal (Section 5).
o Added more profile requirements (Appendix A). o Added more profile requirements (Appendix A).
B.2. Version -01 to -02 B.3. 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 40, line 18 skipping to change at page 44, line 41
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.3. Version -00 to -01 B.4. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
o Defined error handling on the KDC (Sections 4.2 and 6.2). o Defined error handling on the KDC (Sections 4.2 and 6.2).
o Updated format of the Key Distribution Response as a whole o Updated format of the Key Distribution Response as a whole
(Section 4.2). (Section 4.2).
o Generalized format of 'pub_keys' in the Key Distribution Response o Generalized format of 'pub_keys' in the Key Distribution Response
 End of changes. 107 change blocks. 
264 lines changed or deleted 488 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/