--- 1/draft-ietf-ace-key-groupcomm-03.txt 2020-01-15 06:13:17.764909345 -0800 +++ 2/draft-ietf-ace-key-groupcomm-04.txt 2020-01-15 06:13:17.864911895 -0800 @@ -1,19 +1,19 @@ ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track M. Tiloca -Expires: May 7, 2020 RISE AB - November 04, 2019 +Expires: July 18, 2020 RISE AB + January 15, 2020 Key Provisioning for Group Communication using ACE - draft-ietf-ace-key-groupcomm-03 + draft-ietf-ace-key-groupcomm-04 Abstract This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,94 +22,98 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 - 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 - 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 - 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Keying Material Provisioning and Group Membership Management 11 - 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 12 - 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 21 - 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 22 - 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 24 - 4.5. Retrieval of Public Keys for Group Members . . . . . . . 24 - 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 25 - 4.7. Retrieval of Keying Material Version . . . . . . . . . . 25 - 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 26 - 5. Removal of a Node from the Group . . . . . . . . . . . . . . 26 - 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 27 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 29 - 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 29 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 8.1. ACE Authorization Server Request Creation Hints Registry 30 - 8.2. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 30 - 8.3. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 31 - 8.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 32 - 8.5. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 32 - 8.6. Sequence Number Synchronization Method Registry . . . . . 33 - 8.7. Expert Review Instructions . . . . . . . . . . . . . . . 34 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 9.2. Informative References . . . . . . . . . . . . . . . . . 35 - Appendix A. Requirements on Application Profiles . . . . . . . . 37 - Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 39 - B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39 - B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 39 - B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 40 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 + 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 + 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8 + 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Keying Material Provisioning and Group Membership Management 12 + 4.1. Interface at KDC . . . . . . . . . . . . . . . . . . . . 13 + 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 23 + 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 24 + 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 26 + 4.5. Retrieval of Public Keys for Group Members . . . . . . . 26 + 4.6. Retrieval of Group Policies . . . . . . . . . . . . . . . 27 + 4.7. Retrieval of Keying Material Version . . . . . . . . . . 27 + 4.8. Group Leaving Request . . . . . . . . . . . . . . . . . . 28 + 5. Removal of a Node from the Group . . . . . . . . . . . . . . 28 + 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 29 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 31 + 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 31 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 32 + 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 33 + 8.3. ACE Authorization Server Request Creation Hints Registry 33 + 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 34 + 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 34 + 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 35 + 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 36 + 8.8. Sequence Number Synchronization Method Registry . . . . . 36 + 8.9. Expert Review Instructions . . . . . . . . . . . . . . . 37 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 9.2. Informative References . . . . . . . . . . . . . . . . . 39 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Appendix A. Requirements on Application Profiles . . . . . . . . 41 + Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 43 + B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 43 + 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 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to define the message exchanges used to request, distribute and renew the keying material in a group communication scenario, e.g. based on multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR [RFC7049], so CBOR is the format used in this specification. However, using JSON [RFC8259] instead of CBOR is possible, using the conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. Profiles that use group communication can build on this document, by defining a number of details such as the exact group communication 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 keying material is generated and distributed to the group members (rekeying), when membership changes. A key management scheme performs the actual distribution of the updated keying material to the group. In particular, the key management scheme rekeys the current group members when a new node joins the group, and the remaining group members when a node leaves the group. Rekeying mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]. @@ -159,33 +163,32 @@ Figure 1: Key Distribution Participants The following participants (see Figure 1) take part in the authorization and key distribution. o Client (C): node that wants to join the group communication. It can request write and/or read rights. o Authorization Server (AS): same as AS in the ACE Framework; it - enforces access policies, and knows if a node is allowed to join - the group with write and/or read rights. + enforces access policies, and knows if a node is allowed to join a + given group with write and/or read rights. o Key Distribution Center (KDC): maintains the keying material to 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 Framework. During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material. In addition, it provides the latest keying material to group members - when requested. If required by the application, the KDC renews - and re-distributes the keying material in the group when - membership changes. + when requested or, if required by the application, when membership + changes. o Dispatcher: entity through which the Clients communicate with the group and which distributes messages to the group members. Examples of dispatchers are: the Broker node in a pub-sub setting; a relayer node for group communication that delivers group messages as multiple unicast messages to all group members; an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. @@ -198,21 +201,47 @@ o A node to leave the group of for the KDC to remove a current member of the group (Section 5). o Retrieving keying material as a current group member (Section 4.3 and Section 4.4). o Renewing and re-distributing the group keying material (rekeying) 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 - 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 | | | Member / | | | | | | Authorization Request | | | Defined | |---------------------------->| | | in the | | | | | ACE | | Authorization Response | | | framework | |<----------------------------| | | | | | | @@ -411,23 +440,25 @@ After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in 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 parameter 'rsnonce' defined in Section Section 3.3.3, specifying a dedicated nonce N_S generated by the KDC. The Client may use this nonce for proving possession of its own private key (see the - 'client_cred_verify' parameter in Section 4). + 'client_cred_verify' parameter in Section 4). 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 defined in Section 3.3.1 and Section 3.3.2 of this specification, respectively. The 'sign_info' parameter MUST be present if the POST request included the 'sign_info' parameter with value Null. If present, the 'sign_info' parameter of the 2.01 (Created) response is a CBOR array formatted as follows. o The first element 'sign_alg' is an integer or a text string, @@ -445,42 +476,49 @@ o The third element 'sign_key_parameters' indicates the parameters of the key used with the signature algorithm. Its structure depends on the value of 'sign_alg'. It is REQUIRED of the application profiles to define specific values for this parameter (REQ5). If no parameters of the key used with the signature algorithm are specified, 'sign_key_parameters' MUST be encoded as the CBOR simple value Null. The 'pub_key_enc' parameter MUST be present if the POST request 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 - integer, indicating the encoding of public keys used in the group. + the 'pub_key_enc' parameter of the 2.01 (Created) response is either + a CBOR integer indicating the encoding of public keys used in the + 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" Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is REQUIRED of the application profiles to define specific values to use for this parameter (REQ6). The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters formatted as in the response is given below. sign_info_res = [ sign_alg : int / tstr, sign_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) response may include further parameters, e.g. according to the 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 The 'sign_info' parameter is an OPTIONAL parameter of the AS Request Creation Hints message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information and parameters about the signature algorithm and the public keys to be used between the Client and the RS. Its exact content is application specific. In this specification and in application profiles building on it, @@ -518,23 +556,22 @@ This section defines the interface available at the KDC. Moreover, this section specifies how the clients can use this interface to join a group, leave a group, retrieve new keying material or policies. During the first exchange with the KDC ("Joining"), the Client sends a request to the KDC, specifying the group it wishes to join (see Section 4.2). Then, the KDC verifies the access token and that the Client is authorized to join that group. If so, it provides the Client with the keying material to securely communicate with the other members of the group. Whenever used, the Content-Format in - messages containing a payload is set to application/cbor. - - TODO: Do we need to define a new Content-Format cbor+ace-groupcomm? + messages containing a payload is set to application/ace- + groupcomm+cbor, as defined in Section 8.2. When the Client is already a group member, the Client can use the interface at the KDC to perform the following actions: o The Client can (re-)get the current keying material, for cases such as expiration, loss or suspected mismatch, due to e.g. reboot or missed group rekeying. This is described in Section 4.3. o The Client can retrieve a new individual key, or new input material to derive it. This is described in Section 4.4. @@ -567,30 +604,33 @@ specification is used. Other applications that run on a KDC implementing this specification MUST NOT use this same resource. o /ace-group/gid : one sub-resource to /ace-group is implemented for each group the KDC manages. These resources are identified by the group identifiers of the groups the KDC manages (in this example, the group identifier has value "gid"). These resources support GET and POST method. o /ace-group/gid/pub-key : this sub-resource is fixed and supports - GET and POST methods. + GET and FETCH methods. o /ace-group/gid/policies: this sub-resource is fixed and supports the GET method. o /ace-group/gid/ctx-num: this sub-resource is fixed and supports the GET method. - o /ace-group/gid/node: this sub-resource is fixed and supports GET - and POST methods. + o /ace-group/gid/node: one sub-resource to /ace-group/gid is + implemented for each node in the group the KDC manages. These + resources are identified by the node name (in this example, the + node name has value "node"). These resources support GET, PUT and + DELETE methods. The details for the handlers of each resource are given in the following sections. These endpoints are used to perform the operations introduced in Section 4. Note that the url-path given here are default names: implementations are not required to use these names, and can define their own instead. 4.1.1. ace-group No handlers are implemented for this resource. @@ -615,135 +655,173 @@ 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 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 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 provided by the AS. o 'client_cred', with value the public key or certificate of the - Client, encoded as a CBOR byte string. If the KDC is managing - (collecting from/distributing to the Client) the public keys of - the group members, this field contains the public key of the - Client. The default encoding for public keys is COSE Keys. - Alternative specific encodings of this parameter MAY be defined in - applications of this specification (OPT1). + Client, encoded as a CBOR byte string. This field contains the + public key of the Client. This field is used if the KDC is + managing (collecting from/distributing to the Client) the public + keys of the group members, and if the Client's role in the group + will require for it to send messages to the group. The default + 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 [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C generated by the Client. This parameter MUST be present if the 'client_cred' parameter is present. o 'client_cred_verify', encoded as a CBOR byte string. This parameter MUST be present if the 'client_cred' parameter is present. This parameter contains a signature computed by the 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 (Created) response to the token POST request (see Section 3.3), while N_C is the nonce generated by the Client and specified in - the 'cnonce' parameter above. The Client computes the signature - by using its own private key, whose corresponding public key is - either directly specified in the 'client_cred' parameter or - included in the certificate specified in the 'client_cred' - parameter. + the 'cnonce' parameter above. If the token is not being posted + (e.g. if it is used directly to validate TLS instead), it is + REQUIRED of the specific profile to define how the nonce N_S is + generated (REQ17). The Client computes the signature by using its + own private key, whose corresponding public key is either directly + specified in the 'client_cred' parameter or included in the + certificate specified in the 'client_cred' parameter. o 'pub_keys_repos', can be present if a certificate is present in - the 'client_cred' field, with value a list of public key - repositories storing the certificate of the Client. This - parameter is encoded as a CBOR array of CBOR text strings, each of - which specifies the URI of a key repository. + the 'client_cred' field, with value the URI of the certificate of + the Client. This parameter is encoded as a CBOR text string. + Alternative specific encodings of this parameter MAY be defined in + applications of this specification (OPT3). 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. + 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 - present), the handler MUST respond with 4.00 (Bad Request) error + If the request is not formatted correctly (e.g. unknown, not-expected + fields present, or expected fields with incorrect format), the + handler MUST respond with 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. - If verification succeeds, the handler adds the public key indicated - in "client_cred" to the list of public keys stored for the group - identified by "gid". The handler returns a 2.01 (Created) message - containing the symmetric group keying material, the group policies - and all the public keys of the current members of the group, if the - KDC manages those and the Client requested them. The payload of the - response is formatted as a CBOR map which MAY contain the following - fields, which, if included, MUST have the corresponding values: + If verification succeeds, the handler adds the retrieved public key + of the joining node to the list of public keys stored for the group + identified by "gid". Moreover, the handler assigns a name to the + node (e.g. "node1"), and creates a sub-resource to /ace-group/gid/ at + the KDC (e.g. "/ace-group/gid/node1"). The handler returns a 2.01 + (Created) message containing the symmetric group keying material, the + group policies and all the public keys of the current members of the + group, if the KDC manages those and the Client requested them. The + 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 Groupcomm Key" Registry. Implementations MUST verify that the key type matches the application profile being used, if present, as registered in the "ACE Groupcomm Key" registry. o 'key', containing the keying material for the group communication, or information required to derive it. o 'num', containing the version number of the keying material for the group communication, formatted as an integer. The initial - version MUST be set to 0 at the KDC. + 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 - 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 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. +----------+----------------+---------+-------------------------+ | Name | Key Type Value | Profile | Description | +----------+----------------+---------+-------------------------+ | Reserved | 0 | | This value is reserved | +----------+----------------+---------+-------------------------+ Figure 4: Key Type Values Optionally, the response MAY contain the following parameters, which, if included, MUST have the corresponding values: - o 'profile', with value a CBOR integer that MUST be used to uniquely - identify the application profile for group communication. The - value MUST be registered in the "ACE Groupcomm Profile" Registry. + o 'ace-groupcomm-profile', with value a CBOR integer that MUST be + used to uniquely identify the application profile for group + 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 the group communication, encoded as a CBOR unsigned integer or floating-point number. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what specified in Section 2 of [RFC7519]. 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 public keys of all the group members paired with the respective member identifiers. The default encoding for public keys is COSE Keys, so the default encoding for 'pub_keys' is a CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which contains the public keys of all the members of the group. In particular, each COSE Key in the COSE_KeySet includes the identifier of the corresponding group member as value of its 'kid' 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 - specified in the application profile (REQ8). + specified in the application profile (REQ9). o 'group_policies', with value a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policy" Registry. This specification defines the two elements "Sequence Number Synchronization Method" and "Key Update Check Interval", which are summarized in Figure 5. Application profiles that build on this document MUST specify the exact content format of included map - entries (REQ9). + entries (REQ14). +-----------------+-------+----------|--------------------|------------+ | Name | CBOR | CBOR | Description | Reference | | | label | type | | | |-----------------+-------+----------|--------------------|------------| | Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | | Synchronization | | | cipient node to | document]] | | Method | | | synchronize with | | | | | | sequence numbers | | | | | | of a sender node. | | @@ -758,100 +836,107 @@ | Check Interval | | | in seconds, to | document]] | | | | | check for new | | | | | | keying material at | | | | | | the KDC | | +-----------------+-------+----------|--------------------|------------+ Figure 5: ACE Groupcomm Policies o 'mgt_key_material', encoded as a CBOR byte string and containing the administrative keying material to participate in the group - rekeying performed by the KDC. The exact format and content - depend on the specific rekeying scheme used in the group, which - MAY be specified in the application profile (OPT3). + rekeying performed by the KDC. The application profile MUST + define if this field is used, and if used then MUST specify the + 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 - specify how exactly the keying material is used to protect the group - communication (REQ10). + specify the communication protocol that members of the group use to + 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. 4.1.2.2. GET Handler The GET handler returns the symmetric group keying material for the group identified by "gid". 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. + 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) - message containing the symmetric group keying material, the group - policies and all the public keys of the current members of the group. - The payload of the response is formatted as a CBOR map which MUST - contain the parameters 'kty','key' and 'num' specified in - Section 4.1.2.1. + message containing the symmetric group keying material. The payload + of the response is formatted as a CBOR map which MUST contain the + parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. - The payload MAY also include the parameters 'profile', 'exp' and - 'mgt_key_material' parameters specified in Section 4.1.2.1. + The payload MAY also include the parameters 'ace-groupcomm-profile', + 'exp' and 'mgt_key_material' parameters specified in Section 4.1.2.1. 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 members. The handler expects a request with payload formatted as a CBOR map. The payload of this request is a CBOR Map that MUST contain the following fields: o '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 group identified by "gid". The specific format of public keys as well as identifiers of group members MUST be specified by the - application profile (REQ11, REQ8). + application profile (OPT1, REQ9). 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. - 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 the current group members for which the identifier matches with one of those indicated in the request. Then, the handler returns a 2.05 (Content) message response with payload 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 those group members including the respective member identifiers. If the KDC does not store any public key associated with the specified member identifiers, the handler returns a response with payload formatted as a CBOR byte string of zero length. The specific format of public keys as well as of identifiers of group members is specified by the application profile - (REQ11, REQ8). + (OPT1, REQ9). The handler MAY enforce one of the following policies, in order to handle possible identifiers that are included in the 'get_pub_keys' parameter of the request but are not associated to any current group member. Such a policy MUST be specified by the application profile - (REQ12) + (REQ13) o The KDC silently ignores those identifiers. o The KDC retains public keys of group members for a given amount of time after their leaving, before discarding them. As long as such public keys are retained, the KDC provides them to a requesting Client. 4.1.3.2. GET Handler @@ -864,22 +949,22 @@ If verification succeeds, the handler returns a 2.05 (Content) message containing the public keys of all the current group members, for the group identified by "gid". The payload of the response is formatted as a CBOR map containing only the 'pub_keys' parameter from Section 4.1.2.1, which encodes the list of public keys of all the group members including the respective member identifiers. If the KDC does not store any public key for the group, the handler returns a response with payload formatted as a CBOR byte string of zero length. The specific format of public keys as well as of identifiers - of group members is specified by the application profile (REQ11, - REQ8). + of group members is specified by the application profile (OPT1, + REQ9). 4.1.4. ace-group/gid/policies This resource implements a GET handler. 4.1.4.1. GET Handler The handler expects a GET request. The handler verifies that the group identifier of the /ace-group/gid @@ -889,21 +974,21 @@ If verification succeeds, the handler returns a 2.05 (Content) message containing the list of policies for the group identified by "gid". The payload of the response is formatted as a CBOR map including only the parameter 'group_policies' defined in Section 4.1.2.1 and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a zero-length CBOR byte string. The specific format and meaning of group policies MUST be specified - in the application profile (REQ13). + in the application profile (REQ14). 4.1.5. ace-group/gid/ctx-num This resource implements a GET handler. 4.1.5.1. GET Handler The handler expects a GET request. The handler verifies that the group identifier of the /ace-group/gid @@ -913,99 +998,130 @@ If verification succeeds, the handler returns a 2.05 (Content) message containing an integer that represents the version number of the symmetric group keying material. This number is incremented on the KDC every time the KDC updates the symmetric group keying material. The payload of the response is formatted as a CBOR integer. 4.1.6. ace-group/gid/node - This resource implements GET and POST handlers. + 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 - identified by "gid". + The PUT handler is used to get the KDC to produce and return + 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 payload of this request is a CBOR Map that MAY contain only the 'scope' field as specified in Section 4.1.2.1. The handler verifies that the group identifier of the /ace-group/gid path is a subset of the 'scope' stored in the access token associated to this client. If verification fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. If the request contained a 'scope' field, the handler MUST extract the roles for that client. If the value is such that the KDC cannot extract all the necessary information to understand and process it correctly (e.g. unrecognized roles), the KDC MUST respond with a 4.00 (Bad Request) error message. If verification succeeds, the handler removes the client from the group identified by "gid", for specific roles if roles were specified in the 'scope' field, or for all roles. That includes removing the public key of the client if the KDC keep tracks of that. Then, the - handler returns a 2.05 (Content) message with empty payload. - -4.1.6.2. GET Handler - - The handler expects a GET request. - - The handler verifies that the group identifier of the /ace-group/gid - path is a subset of the 'scope' stored in the access token associated - to this client. If verification fails, the KDC MUST respond with a - 4.01 (Unauthorized) error message. - - If verification succeeds, the handler returns a 2.05 (Content) - message containing newly-generated individual keying material for the - Client, or information enabling the Client to derive it. The payload - of the response is formatted as a CBOR map. The specific format of - newly-generated individual keying material for group members, or of - the information to derive it, and corresponding CBOR label, MUST be - specified in the application profile (REQ14) and registered in - Section 8.2. + handler delete the sub-resource /node and returns a 2.02 (Deleted) + message with empty payload. 4.2. Joining Exchange Figure 6 gives an overview of the Joining exchange between Client and KDC, when the Client first joins a group. Client KDC | | |-------- Joining Request: POST /ace-group/gid --------->| | | |<--------- Joining Response: 2.01 (Created) ----------- | - | | + | Location-Path = "/ace-group/gid/node" | Figure 6: Message Flow of First Exchange for Group Joining If not previously established, the Client and the KDC MUST first - establish a pairwise secure communication channel (REQ15). This can + establish a pairwise secure communication channel (REQ16). This can be achieved, for instance, by using a transport profile of ACE. The Joining exchange MUST occur over that secure channel. The Client and the KDC MAY use that same secure channel to protect further pairwise communications that must be secured. The secure communication protocol is REQUIRED to establish the secure channel by using the proof-of-possession key bound to the access token. As a result, the proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC. To join the group, the Client sends a CoAP POST request to the /ace- group/gid endpoint at the KDC, where gid is the group identifier of the group to join, formatted as specified in Section 4.1.2.1. This group identifier is the same as the 'scope' value of the - Authorization Request/Response, or it can be retrieved from it. + 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 new group keying material and securely distribute it to all the current group members, upon a new node's joining the group. To this end, the KDC uses the message format of the Joining Response (see Section 4.1.2.1). Application profiles may define alternative ways of retrieving the keying material, such as sending separate requests to different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, Section 4.1.4.1). After distributing the new group keying material, the KDC MUST increment the version number of the keying material. @@ -1017,22 +1133,22 @@ Joining response, or to a pre-configured value. Then, if it wants to continue participating in the group communication, the node has to request new updated keying material from the KDC. The Client may need to request the latest group keying material also upon receiving messages from other group members without being able to retrieve the material to correctly decrypt them. This may be due to a previous update of the group keying material (rekeying) triggered by the KDC, that the Client was not able to receive or decrypt. To this end, the Client sends a CoAP GET request to the - /ace-group/gid endpoint at the KDC, formatted as specified in - Section 4.1.2.2. + /ace-group/gid/node endpoint at the KDC, formatted as specified in + Section 4.1.6.2. Note that policies can be set up so that the Client sends a Key Re- Distribution Request to the KDC only after a given number of unsuccessfully decrypted incoming messages. It is application dependent and pertaining to the particular message exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up policies that instruct clients to retain unsuccessfully decrypted messages and for how long, so that they can be decrypted after getting updated keying material, rather than just considered non valid messages to discard right away (OPT4). @@ -1040,31 +1156,31 @@ The same Key Distribution Request could also be sent by the Client 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. If that is the case, the Client will receive from the KDC the same group keying material it already has in memory. Figure 7 gives an overview of the exchange described above. Client KDC | | - |----- Key Distribution Request: GET ace-group/gid ----->| + |--- Key Distribution Request: GET ace-group/gid/node -->| | | |<----- Key Distribution Response: 2.05 (Content) -------| | | Figure 7: Message Flow of Key Distribution Request-Response Alternatively, the re-distribution of keying material can be 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. o Can send the Key Distribution Response as one or multiple multicast requests to the members of the group, using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. o Can send unicast requests to each Client over a secure channel, with the same payload as the Key Distribution Response. o Can act as a publisher in a pub-sub scenario, and update the @@ -1077,66 +1193,67 @@ 4.4. Retrieval of New Keying Material Beside possible expiration and depending on what part of the keying 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 example, if the Client uses an individual key to protect outgoing traffic and has to renew it, the node may request a new one, or new input material to derive it, without renewing the whole group keying material. To this end, the client performs a Key Renewal Request/ - Response exchange with the KDC, that is a CoAP GET request to the + Response exchange with the KDC, that is a CoAP PUT request to the /ace-group/gid/node endpoint at the KDC, where gid is the group - identifier, and 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. Client KDC | | - |---- Key Renewal Request: GET ace-group/gid/node --->| + |---- Key Renewal Request: PUT ace-group/gid/node --->| | | |<----- Key Renewal Response: 2.05 (Content) ---------| | | Figure 8: Message Flow of Key Renewal Request-Response Note the difference between the Key Distribution Request and the Key Renewal Request: while the first one only triggers distribution (the renewal might have happened independently, e.g. because of expiration), the second one triggers the KDC to produce new individual keying material for the requesting node. 4.5. Retrieval of Public Keys for Group Members 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 - 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 is the group identifier, and formatted as defined in Section 4.1.3.2 and Section 4.1.3.1. Figure 9 and Figure 10 give an overview of the exchanges described above. Client KDC | | |---- Public Key Request: GET /ace-group/gid/pub-key --->| | | |<--------- Public Key Response: 2.05 (Content) ---------| | | Figure 9: Message Flow of Public Key Exchange to Request All Members Public Keys 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) ---------| | | Figure 10: Message Flow of Public Key Exchange to Request Specific Members Public Keys 4.6. Retrieval of Group Policies A node in the group can contact the KDC to retrieve the current group @@ -1171,23 +1288,23 @@ |----- Version Request: GET ace-group/gid/ctx-num ----->| | | |<--------- Version Response: 2.05 (Content) -----------| | | Figure 12: Message Flow of Version Request-Response 4.8. Group Leaving Request A node can actively request to leave the group. In this case, the - Client sends a CoAP POST request to the endpoint /ace-group/gid/node - at the KDC, where gid is the group identifier, formatted as defined - in Section 4.1.6.1 + Client sends a CoAP DELETE request to the endpoint /ace-group/gid/ + node at the KDC, where gid is the group identifier and node the + node's name, formatted as defined in Section 4.1.6.3 Alternatively, a node may be removed by the KDC, without having explicitly asked for it. This is further discussed in Section 5. 5. Removal of a Node from the Group This section describes the different scenarios according to which a node ends up being removed from the group. If the application requires forward security, the KDC MUST generate @@ -1224,71 +1341,72 @@ Either case, once aware that a node is not authorized anymore, the KDC has to remove the unauthorized node from the list of group members, if the KDC keeps track of that. 6. ACE Groupcomm Parameters This specification defines a number of fields used during the second part of the message exchange, after the ACE Token POST exchange. The table below summarizes them, and specifies the CBOR key to use - instead of the full descriptive name. + 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 | | | Key | | | - +--------------------+--------+-----------------------+-------------+ + +-----------------------+--------+---------------------+------------+ | scope | TBD | array | Section | | | | | 4.1.2.1 | | | | | | | get_pub_keys | TBD | array | Section | | | | | 4.1.2.1 | | | | | | | client_cred | TBD | byte string | Section | | | | | 4.1.2.1 | | | | | | | cnonce | TBD | byte string | Section | | | | | 4.1.2.1 | | | | | | | client_cred_verify | TBD | byte string | Section | | | | | 4.1.2.1 | | | | | | | pub_keys_repos | TBD | array | Section | | | | | 4.1.2.1 | | | | | | - | kty | TBD | int / byte string | Section | + | gkty | TBD | int / byte string | Section | | | | | 4.1.2.1 | | | | | | | key | TBD | see "ACE Groupcomm | Section | | | | Key" Registry | 4.1.2.1 | | | | | | | num | TBD | int | Section | | | | | 4.1.2.1 | | | | | | - | profile | TBD | int | Section | + | ace-groupcomm-profile | TBD | int | Section | | | | | 4.1.2.1 | | | | | | | exp | TBD | int / float | Section | | | | | 4.1.2.1 | | | | | | | pub_keys | TBD | byte string | Section | | | | | 4.1.2.1 | | | | | | | group_policies | TBD | map | Section | | | | | 4.1.2.1 | | | | | | | mgt_key_material | TBD | byte string | Section | | | | | 4.1.2.1 | | | | | | | get_pub_keys | TBD | array | Section | | | | | 4.1.3.1 | - +--------------------+--------+-----------------------+-------------+ + +-----------------------+--------+---------------------+------------+ 7. Security Considerations When a Client receives a message from a sender for the first time, it needs to have a mechanism in place to avoid replay, e.g. Appendix B.2 of [RFC8613]. The KDC must renew the group keying material upon its expiration. The KDC should renew the keying material upon group membership @@ -1363,21 +1481,80 @@ Compared to a scenario where the transfer does not use block-wise, depending on how fast the keying material is changed, the nodes might consume a larger amount of the network bandwidth resending the blocks again and again, which might be problematic. 8. IANA Considerations 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 Authorization Server Request Creation Hints" Registry defined in Section 8.1 of [I-D.ietf-ace-oauth-authz]. o Name: sign_info o CBOR Key: TBD (range -256 to 255) o Value Type: any @@ -1384,35 +1561,34 @@ o Reference: [[This specification]] o Name: pub_key_enc o CBOR Key: TBD (range -256 to 255) o Value Type: integer o Reference: [[This specification]] - o Name: rsnonce o CBOR Key: TBD (range -256 to 255) o Value Type: byte string o Reference: [[This specification]] -8.2. ACE Groupcomm Parameters Registry +8.4. ACE Groupcomm Parameters Registry This specification establishes the "ACE Groupcomm Parameters" IANA Registry. The Registry has been created to use the "Expert Review 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: o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o 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 negative integer, or a string. @@ -1421,26 +1597,26 @@ to the registry that defines its type, when that depends on another item. o Reference: This contains a pointer to the public specification for the item. This Registry has been initially populated by the values in Section 6. The Reference column for all of these entries refers to 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. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are - provided in Section 8.7. + provided in Section 8.9. The columns of this Registry are: o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. o Key Type Value: This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a string. @@ -1453,26 +1629,26 @@ o Description: This field contains a brief description of the keying material. o References: This contains a pointer to the public specification for the format of the keying material, if one exists. This Registry has been initially populated by the values in Figure 4. The specification column for all of these entries will be this document. -8.4. ACE Groupcomm Profile Registry +8.6. ACE Groupcomm Profile Registry This specification establishes the "ACE Groupcomm Profile" IANA Registry. The Registry has been created to use the "Expert Review 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 specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the application profile, to be used as value of the profile attribute. o Description: Text giving an overview of the application profile @@ -1483,26 +1659,26 @@ policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. o Reference: This contains a pointer to the public specification of 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 Registry. The Registry has been created to use the "Expert Review 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 specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the group communication policy. o CBOR label: The value to be used to identify this group communication policy. Key map labels MUST be unique. The label @@ -1519,45 +1695,45 @@ o Description: This field contains a brief description for this group communication policy. o Reference: This field contains a pointer to the public specification providing the format of the group communication policy, if one exists. 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 Method" IANA Registry. The Registry has been created to use the "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 require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: o Name: The name of the sequence number synchronization method. o Value: The value to be used to identify this sequence number synchronization method. o Description: This field contains a brief description for this sequence number synchronization method. o Reference: This field contains a pointer to the public specification describing the sequence number synchronization method. -8.7. Expert Review Instructions +8.9. Expert Review Instructions The IANA Registries established in this document are defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points: o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure @@ -1593,39 +1769,44 @@ [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-11 (work in progress), October 2019. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 - Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 - (work in progress), October 2019. + Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 + (work in progress), December 2019. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization 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] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", - draft-ietf-core-oscore-groupcomm-05 (work in progress), - July 2019. + draft-ietf-core-oscore-groupcomm-06 (work in progress), + November 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . + [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", @@ -1634,33 +1815,34 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.dijk-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication 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] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for 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] Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile - of ACE", draft-ietf-ace-mqtt-tls-profile-01 (work in - progress), October 2019. + of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in + progress), December 2019. [I-D.ietf-ace-oscore-profile] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-ietf-ace- oscore-profile-08 (work in progress), July 2019. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol @@ -1675,20 +1857,24 @@ [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, DOI 10.17487/RFC2094, July 1997, . [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, DOI 10.17487/RFC2627, June 1999, . + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in @@ -1699,121 +1885,159 @@ [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . -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 specification,for the convenience of application profile designers. o REQ1: Specify the encoding and value of the identifier of group or topic of 'scope' (see Section 3.1). o REQ2: Specify the encoding and value of roles of 'scope' (see Section 3.1). - o REQ3: Optionally, specify the acceptable values for 'sign_alg' - (see Section 3.3). + o REQ3: If used, specify the acceptable values for 'sign_alg' (see + Section 3.3). - o REQ4: Optionally, specify the acceptable values for - 'sign_parameters' (see Section 3.3). + o REQ4: If used, specify the acceptable values for 'sign_parameters' + (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). - 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). o REQ7: Specify the exact format of the 'key' value (see Section 4.1.2.1). - o REQ8: Specify the acceptable values of 'kty' (see + o REQ8: Specify the acceptable values of 'gkty' (see 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). - o REQ10: Optionally, specify the format and content of - 'group_policies' entries (see Section 4.1.2.1). - - o REQ11: Specify the communication protocol the members of the group + o REQ10: Specify the communication protocol the members of the group must use (e.g., multicast CoAP). - o REQ12: Specify the security protocol the group members must use to + o REQ11: Specify the security protocol the group members must use to protect their communication (e.g., group OSCORE). This must 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). - o REQ14: Optionally, specify the encoding of public keys, of - 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see - Section 4.1.2.1). - - o REQ15: Specify policies at the KDC to handle id that are not + o REQ13: Specify policies at the KDC to handle ids that are not included in get_pub_keys (see Section 4.1.3.1). - o REQ16: Specify the format and content of 'group_policies' (see - Section 4.1.2.1). + o REQ14: If used, specify the format and content of 'group_policies' + 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, 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 [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see 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 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see Section 4.1.2.1). o OPT2: Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (see Section 3.3). - o OPT3: Optionally, specify the format and content of - 'mgt_key_material' (see Section 4.1.2.1). + o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the + default is not used (see Section 4.1.2.1). o OPT4: Optionally, specify policies that instruct clients to retain unsuccessfully decrypted messages and for how long, so that they - can be decrypted after getting updated keying material (OPT4). + 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 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 related parameters, during the Token POST (Section 3.3). o Restructured KDC interface, with new possible operations (Section 4). o Client PoP signature for the Joining Request upon joining (Section 4.1.2.1). o Revised text on group member removal (Section 5). o Added more profile requirements (Appendix A). -B.2. Version -01 to -02 +B.3. Version -01 to -02 o Editorial fixes. o Distinction between transport profile and application profile (Section 1.1). o New parameters 'sign_info' and 'pub_key_enc' to negotiate parameter values for signature algorithm and signature keys (Section 3.3). @@ -1842,21 +2066,21 @@ o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), populated with the values in Section 9. o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated with two entries "Sequence Number Synchronization Method" and "Key Update Check Interval" (Section 4.2). o Improved list of requirements for application profiles (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 Request (Section 3.1). o Defined error handling on the KDC (Sections 4.2 and 6.2). o Updated format of the Key Distribution Response as a whole (Section 4.2). o Generalized format of 'pub_keys' in the Key Distribution Response