Re: [Ace] draft-ietf-ace-key-groupcomm-13
Cigdem Sengul <cigdem.sengul@gmail.com> Wed, 25 August 2021 21:53 UTC
Return-Path: <cigdem.sengul@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5E23A14B8 for <ace@ietfa.amsl.com>; Wed, 25 Aug 2021 14:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.419
X-Spam-Level:
X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FUZZY_CREDIT=1.678, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcKWwmO7lpAp for <ace@ietfa.amsl.com>; Wed, 25 Aug 2021 14:53:04 -0700 (PDT)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6833A14AF for <ace@ietf.org>; Wed, 25 Aug 2021 14:53:03 -0700 (PDT)
Received: by mail-vk1-xa2c.google.com with SMTP id d30so242575vkl.12 for <ace@ietf.org>; Wed, 25 Aug 2021 14:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xy95LfGBj63/xNeCnfZ0kdTXIIkEgsx6y+trc1+N/kQ=; b=OOH5RgarZ+pe30+4RDhi5BJwoelLn3gLYlFJBkWEjyluyTOb2DyKdC8KHJ06EkUEOw z5NNKu3lDBMocDANUBVWkkHvoVJ8myb4tFV+or6OO/Wk9kz1LqZ7Qx240VeNe1z8PBBd mjA1lSkF+UKOm6wjW68Y+rXSH0FZmPg9goWXJRn6Nqs0w1Rawb4ho7R+HZkpmLdKrTQL 69IDZurvI+b64qXLSEXTgupNFC1MZzqazwC+vCbVEnak6VyjB9XXx+4Vi8Yqm++FYRkI GpAfBF9YYQnfEsrCclHOYBaOb4EM84ovuR1fhEWapx6y662wmeqcVwxUPFJcwocPxJDt V8Tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xy95LfGBj63/xNeCnfZ0kdTXIIkEgsx6y+trc1+N/kQ=; b=aqDZbiGjC8n8PgohAd1t7AZoepxlu5ieVu2tgsmJGyz6PWvIa8nW/Rh1FVt6LjMbFb RHlQdXm7iE0/drd6mp0LrZvC0o6fIjD8F9nzIkAHaM1fLAh0WFFoS2AcUgKENUymgsqh OEpLuhOdBad1cZbBm1ejfsQ5n+38BlHbvcDuvTv5EkSMxaYy7JzVxAW72N3JlWXf76ks exYDXhNmu2G8Evpxr/P+svwYpG3LhZTSwXPDVDMUYhIvxojpBzHvZdjZfqGfGRGlAw8L 09S+BFX4AtCImgMMindtajb0/UDFRrNllgln0F1/LZa8Wfx8L2ZayOF20gXlnJYhq5I0 vs9w==
X-Gm-Message-State: AOAM530htrnGlAOUHqnnjkdEwj6TenrhnUNL2PSUIjbJkV2w/vM/xNyy 8fNYdFJyc6bE9hmIzxGf9llgb4dH5NVuqMyKlzuyzVyieXi9cw==
X-Google-Smtp-Source: ABdhPJxNMtoWvfGVu1jZPEK0En2lF5oAibWY77NYQyzlwrn/j1Lgx053g35aNz3UutoHMqpmxOeP/0iZlu1Cc5zMXWs=
X-Received: by 2002:a1f:264c:: with SMTP id m73mr288379vkm.1.1629928380343; Wed, 25 Aug 2021 14:53:00 -0700 (PDT)
MIME-Version: 1.0
References: <E59F2C52-F777-4704-90D2-1D04C700A60E@ericsson.com>
In-Reply-To: <E59F2C52-F777-4704-90D2-1D04C700A60E@ericsson.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Wed, 25 Aug 2021 22:52:54 +0100
Message-ID: <CAA7SwCPzy-ALLRtw2Qxt9K3UhEkE8BWSBUFnx-RJJbpZj+n13A@mail.gmail.com>
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
Cc: "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001ea8ce05ca6946e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0>
Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-13
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 21:53:15 -0000
Hello, Here is also my review, as promised. I agree with Göran's comments and tried not to repeat them (but I realise I have the same concern about the presentation of Section 4 - more details below). *General comments:* The draft is quite thorough in providing details about how a node, as a participant of group communication, can get authorisation, join/get information about and leave the group, how a node can be removed, and how the key information is provided to protect the group communication. In the pub-sub draft, we take advantage of all these resources to secure pub-sub communication. In addition to some questions I have about resources (in my detailed comments), most of my comments are focused on improving the readability of the draft. As Göran also mentioned, after defining the available resources, it would be good to explain the flows and then give details of endpoints and examples. This way, it would be possible to understand first the primitives available for securing group communication, then have more detail important for the implementation. Also, reading the draft, it was first not clear how the rekeying was supported, whether it was a push/poll based solution, i.e., whether the KDC pushes new keys or the group participants query for the new key information. Both options are supported, but it would be nice to have one clear section on this with a recommendation (Sections 4.4 and 4.5 look like the main sections for this, but there are several instances throughout the text rekeying is mentioned.) Finally, I've read the draft linearly and revised my comments if something I questioned was answered later; however, I've kept the comment to show where someone can be puzzled, and a forward pointer to the correct section may be appropriate. My comments are within [CS: ]. I hope you find them useful. *Detailed comments:* ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track M. Tiloca Expires: 13 January 2022 RISE AB 12 July 2021 Key Provisioning for Group Communication using ACE draft-ietf-ace-key-groupcomm-13 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. Discussion Venues [SNIP] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 8 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 12 4. Keying Material Provisioning and Group Membership Management . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 17 4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 39 4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 40 4.4. Retrieval of Updated Keying Material . . . . . . . . . . 42 4.5. Requesting a Change of Keying Material . . . . . . . . . 44 4.6. Retrieval of Public Keys and Roles for Group Members . . 45 4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 47 4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 48 4.9. Retrieval of Keying Material Version . . . . . . . . . . 49 4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 50 5. Removal of a Node from the Group . . . . . . . . . . . . . . 50 6. Extended Scope Format . . . . . . . . . . . . . . . . . . . . 52 7. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 54 8. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 55 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 9.1. Update of Keying Material . . . . . . . . . . . . . . . . 57 9.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 10.1. Media Type Registrations . . . . . . . . . . . . . . . . 58 10.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 59 10.3. OAuth Parameters Registry . . . . . . . . . . . . . . . 60 10.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . 60 10.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 61 10.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 61 10.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 62 10.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 63 10.9. Sequence Number Synchronization Method Registry . . . . 63 10.10. Interface Description (if=) Link Target Attribute Values Registry . . . . . . . . . . . . . . . . . . . . . . . 64 10.11. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 64 10.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 65 Palombini & Tiloca Expires 13 January 2022 [Page 2] Internet-Draft Key Provisioning for Group Communication July 2021 10.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 65 10.14. Expert Review Instructions . . . . . . . . . . . . . . . 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 66 11.2. Informative References . . . . . . . . . . . . . . . . . 69 Appendix A. Requirements on Application Profiles . . . . . . . . 70 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 73 B.1. Format of 'sign_info_entry' . . . . . . . . . . . . . . . 74 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 74 C.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 74 C.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 75 C.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 75 C.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 76 C.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 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 [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing [I-D.ietf-core-coap-pubsub]. [CS: Nit: publish-subscribe messaging instead of publishing-subscribing?] The ACE framework is based on CBOR [RFC8949], 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 6.1 and 6.2 of [RFC8949]. 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 shown in Appendix A. If the application requires backward and forward security, new keying material is generated and distributed to the group upon membership changes. [CS: Whose responsibility is this? While I acknowledge that options available become clear in the end, it would be good to define the different operating models, e.g., push/pull based] A key management scheme performs the actual distribution of the new 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]. Palombini & Tiloca Expires 13 January 2022 [Page 3] Internet-Draft Key Provisioning for Group Communication July 2021 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) and Resource Server (RS). This document uses names or identifiers for groups and nodes. Their different meanings are summarized here: * "Group name" is the invariant once established identifier of the group. It is used in the communication between AS, RS and Client to identify the group. [CS: This has confused me earlier with the distinction of security and application group not being clear at the time. Would it be possible to emphasise this is a Security Group Name?] * "GROUPNAME" is the invariant once established text string used in URIs. GROUPNAME maps to the group name of a group, although it is not necessarily the same. * "Group identifier" is the identifier of the group keying material. Opposite to group name and GROUPNAME, this identifier changes over time, when the keying material is updated. * "Node name" is the invariant once established identifier of the node. It is used in the communication between AS, RS and Client to identify a member of the group. * "NODENAME" is the invariant once established text string used in URIs. NODENAME is used to identify a node in a group. This document additionally uses the following terminology: * Transport profile, to indicate a profile of ACE as per Section 5.8.4.3 of [I-D.ietf-ace-oauth-authz]. A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods, if it supports proof-of- possession access tokens, etc. Tranport profiles of ACE include, for instance, [I-D.ietf-ace-oscore-profile], [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. [CS: Tranport -> Transport] Palombini & Tiloca Expires 13 January 2022 [Page 4] Internet-Draft Key Provisioning for Group Communication July 2021 * Application profile, that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation and distribution of keying material. An application profile may define specific procedures and message formats. 2. Overview The full procedure can be separated in two phases: the first one follows the ACE framework, between Client, AS and KDC; the second one is the key distribution between Client and KDC. After the two phases are completed, the Client is able to participate in the group communication, via a Dispatcher entity. +------------+ +-----------+ | AS | | KDC | | | .-------->| | +------------+ / +-----------+ ^ / | / v / +-----------+ +------------+ / +------------+ |+-----------+ | Client |<-' | Dispatcher | ||+-----------+ | |<-------->| |<------->|| Group | +------------+ +------------+ +| members | +-----------+ Figure 1: Key Distribution Participants The following participants (see Figure 1) take part in the authorization and key distribution. * Client (C): node that wants to join the group communication. It can request write and/or read rights. * Authorization Server (AS): same as AS in the ACE Framework; it enforces access policies, and knows if a node is allowed to join a given group with write and/or read rights. * Key Distribution Center (KDC): maintains the keying material to protect group communications, and provides it to Clients 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 or, if required by the application, when membership changes. [CS: It is not clear to me whether the KDC is programmed to rekey when membership changes or that needs to be invoked as a request from one of the group communication participants (which may have, say, a coordinator role). (Again, this is clarified later, but each time I saw it, it triggered the same question.)] Palombini & Tiloca Expires 13 January 2022 [Page 5] Internet-Draft Key Provisioning for Group Communication July 2021 * 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. [CS:Is a Dispatcher always needed? Clients initiating unicast messages to other group members directly p2p?] This document specifies a mechanism for: * Authorizing a new node to join the group (Section 3), and providing it with the group keying material to communicate with the other group members (Section 4). * Allowing a group member to retrieve group keying material (Section 4.4 and Section 4.5). * Allowing a group member to retrieve public keys of other group members (Section 4.6) and to provide an updated public key (Section 4.7). * Allowing a group member to leave the group (Section 5). * Evicting a group member from the group (Section 5). * Renewing and re-distributing the group keying material (rekeying) upon a membership change in the group (Section 4.10 and Section 5). Figure 2 provides a high level overview of the message flow for a 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. This exchange between Client and AS MUST be secured, as specified by the transport profile of ACE used between Client and KDC. 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. This exchange, and all further communications between the Client and the KDC, MUST occur over the secure channel established as a result of the transport profile of ACE used between Client and KDC. After that, a Palombini & Tiloca Expires 13 January 2022 [Page 6] Internet-Draft Key Provisioning for Group Communication July 2021 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 described in the DTLS transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile [I-D.ietf-ace-oscore-profile] of ACE. 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, and the KDC has stored the association between the authorization information from the access token and the secure session with the joining node. [CS: Maybe also clarify here that this potentially triggers re-keying as shown in the figure?] 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. 5. The joining node can communicate securely with the other group members, using the keying material provided in step 3. C AS KDC Group | | | Member / | | | | | | Authorization Request | | | Defined | |-------------------------->| | | in the | | | | | ACE | | Authorization Response | | | framework | |<--------------------------| | | | | | | \ |---------- Token Post --------->| | | | | |------- Joining Request ------->| | | | | |<------ Joining Response -------|-- Group Rekeying -->| | | | | Dispatcher | | | | |<===== Secure group communication =======|===========>| | | | Figure 2: Message Flow Upon New Node's Joining Palombini & Tiloca Expires 13 January 2022 [Page 7] Internet-Draft Key Provisioning for Group Communication July 2021 3. Authorization to Join a Group [SNIP] 3.1. Authorization Request The Authorization Request sent from the Client to the AS is defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the following parameters, which, if included, MUST have the corresponding values: * 'scope', containing the identifier of the specific groups, or topics in the case of pub-sub, that the Client wishes to access, and optionally the roles that the Client wishes to take. [CS: I think we have to include that a pub-sub model may also group nodes based on something other than topics, even though we've written the pub-sub profile based on topic(or topic filter)-based group identifiers. Maybe this is better given just as an example?] This value is a CBOR byte string, wrapping a CBOR array of one or more entries. Palombini & Tiloca Expires 13 January 2022 [Page 8] Internet-Draft Key Provisioning for Group Communication July 2021 By default, each entry is encoded as specified by [I-D.ietf-ace-aif]. The object identifier Toid corresponds to the group name and MUST be encoded as a tstr. The permission set Tperm indicates the roles that the client wishes to take in the group. It is up to the application profiles to define Tperm (REQ2) and register Toid and Tperm to fit the use case. An example of scope using the AIF format is given in Figure 4. Otherwise, each scope entry can be defined as a CBOR array, which contains: [CS: Two options. One recommended? (Though I see that this is better clarified below when explaining extended scope format and how KDC may support multiple... Maybe a forward reference?)] - As first element, the identifier of the specific group or topic, encoded as a tstr. - Optionally, as second element, the role (or CBOR array of roles) that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated to its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s). [CS: What happens if a Client uses the option to select a role but mismatches what is pre-assigned. I expect it's overwritten with what's pre-programmed at the AS? Is there an error message for the mismatch? e.g., "Request inconsistent with the current roles"] In each entry, the encoding of the role identifiers is application specific, and part of the requirements for the application profile (REQ2). In particular, the application profile may specify CBOR values to use for abbreviating role identifiers (OPT7). An example of CDDL definition [RFC8610] of scope using the format above, with group name and role identifiers encoded as text strings is given in Figure 5. [CS: is->are] * 'audience', with an identifier of a KDC. As defined in [I-D.ietf-ace-oauth-authz], other additional parameters can be included if necessary. Palombini & Tiloca Expires 13 January 2022 [Page 9] Internet-Draft Key Provisioning for Group Communication July 2021 gname = tstr permissions = uint . bits roles roles = &( Requester: 1, Responder: 2, Monitor: 3, Verifier: 4 ) scope_entry = AIF_Generic<gname, permissions> scope = << [ + scope_entry ] >> Figure 4: Example CDLL definition of scope, using the default Authorization Information Format gname = tstr role = tstr scope_entry = [ gname , ? ( role / [ 2*role ] ) ] scope = << [ + scope_entry ] >> Figure 5: CDLL definition of scope, using as example group name encoded as tstr and role as tstr 3.2. Authorization Response [SNIP] 3.3. Token Post The Client sends a CoAP POST request including the access token to the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. This request differs from the one defined in [I-D.ietf-ace-oauth-authz], because it allows to transport additional encoding information about the public keys in the group, used for source authentication, as well as any other group parameters. [CS: Transport or request additional information?] The joining node MAY ask for this information from the KDC in the same message it uses to POST the token to the RS. In such a case, the message MUST have Content-Format set to application/ace+cbor defined in Section 8.16 of [I-D.ietf-ace-oauth-authz]. The message payload MUST be formatted as a CBOR map, which MUST include the access token. The CBOR map MAY additionally include the following parameter, which, if included, MUST have the corresponding values: * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple value Null to require information about the signature algorithm, signature algorithm parameters, signature key parameters and on the exact encoding of public keys used in the group. Alternatively, the joining node may retrieve this information by other means. [CS: Reference to them?] After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. The KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor". The payload of the 2.01 response is a CBOR map. If the access token contains a role that requires the Client to send its own public key to the KDC when joining the group, the CBOR map MUST include the parameter 'kdcchallenge' defined in Section 3.3.2, specifying a dedicated challenge N_S generated by the KDC. The Client uses this challenge to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4). Note that the payload format of the response deviates from the one defined in the ACE framework (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]), which has no payload. The KDC MUST store the 'kdcchallenge' value associated to the Client at least until it receives a join request from it (see Section 4.3), to be able to verify that the Client possesses its own private key. [CS: OK, just to clarify? the kdcchallenge is generated and returned in the Authorisation response, and the client uses it to prove ownership of public key on join request. It may be useful to specify more clearly when the challenge parameter is used. (This is clarified much later; I feel explaining the possible flows using the resources beforehand would be better, as I comment later as well.] The same challenge MAY be reused several times by the Client, to generate a new proof of possession, e.g., in case of update of the Palombini & Tiloca Expires 13 January 2022 [Page 12] Internet-Draft Key Provisioning for Group Communication July 2021 public key, or to join a different group with a different signing key, so it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' after the first join is processed as well. If the KDC has already discarded the 'kdcchallenge', that will trigger an error response with a newly generated 'kdcchallenge' that the Client can use to restart the join process, as specified in Section 4.3. If 'sign_info' is included in the request, the KDC MAY include the 'sign_info' parameter defined in Section 3.3.1, with the same encoding. Note that the field 'id' takes the value of the group name for which the 'sign_info_entry' applies to. [CS: This MAY mean that even if the client has sign_info, the KDC may not return this information? What's the reason for this?] 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. Application profiles MAY define the additional parameters to use within this exchange (OPT2). Application profiles of this specification MAY define alternative specific negotiations of parameter values for the signature algorithm and signature keys, if 'sign_info' is not used (OPT1). 3.3.1. 'sign_info' Parameter [CS: It is confusing to read about sign_info in two places (in the previous section and this section). Maybe defer all sign_info -related information to this section?] [SNIP] 3.3.2. 'kdcchallenge' Parameter [CS: The same comment as above, either explained here or above... Otherwise repetitious] [SNIP] 4. Keying Material Provisioning and Group Membership Management [SNIP] 4.1. Interface at the KDC The KDC is configured with the following resources. Note that the root url-path "ace-group" given here are default names: implementations are not required to use these names, and can define their own instead. Each application profile of this specification MUST register a Resource Type for the root url-path (REQ7), and that Resource Type can be used to discover the correct url to access at the KDC. This Resource Type can also be used at the GROUPNAME sub- resource, to indicate different application profiles for different groups. The Interface Description (if=) Link Target Attribute value ace.group is registered (Section 10.10) and can be used to describe this interface. * /ace-group: this resource is invariant once established and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same resource, these applications will collide, and a mechanism will be needed to differentiate the endpoints. This resource supports the FETCH method. * /ace-group/GROUPNAME: one sub-resource to /ace-group is implemented for each group the KDC manages. If the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in Section 3.2) do not match, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name, in order to retrieve the right group (REQ1). [CS: While I understand the purpose of the statement above, it reads confusing. What if the mismatch is an error? E.g., the wrong token is provided for the call, and it should be not authorised, no?] Each resource contains the symmetric group keying material for that group. These resources support the GET and POST methods. * /ace-group/GROUPNAME/pub-key: this resource is invariant once established and contains the public keys of all group members. This resource supports the GET and FETCH methods. [CS: All group members do not need to have public keys, e.g., For pub-sub, its only publishers] * /ace-group/GROUPNAME/policies: this resource is invariant once established and contains the group policies. This resource supports the GET method. Palombini & Tiloca Expires 13 January 2022 [Page 17] Internet-Draft Key Provisioning for Group Communication July 2021 * /ace-group/GROUPNAME/num: this resource is invariant once established and contains the version number for the symmetric group keying material. This sub-resource supports the GET method. * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- group/GROUPNAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value NODENAME). Each resource contains the group and individual keying material for that node. These resources support the GET, PUT and DELETE methods. * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value NODENAME). Each resource contains the individual public keying material for that node. These resources support the POST method. [CS: It also supports FETCH and GET, as detailed later?] It is REQUIRED of the application profiles of this specification to define what operations (e.g., CoAP methods) are allowed on each resource, for each role defined in Section 3.1 according to REQ2 (REQ8). [CS: Just to clarify again, this spec supports the above detailed operations, and it is REQUIRED that the profile, which uses this profile, further constrains the operations and who is allowed to access. And the access may not be based on only role, e.g. NODENAME may be able to PUT under nodes/NODENAME?] 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. 4.1.1. ace-group This resource implements a FETCH handler. 4.1.1.1. FETCH Handler [SNIP] 4.1.2. ace-group/GROUPNAME This resource implements GET and POST handlers. 4.1.2.1. POST Handler The POST handler adds the public key of the client to the list of the group members' public keys and returns the symmetric group keying material for the group identified by GROUPNAME. Note that the group joining exchange is done by the client via this operation, as described in Section 4.3. The handler expects a request with payload formatted as a CBOR map, which MAY contain the following fields, which, if included, MUST have the corresponding values: Palombini & Tiloca Expires 13 January 2022 [Page 19] Internet-Draft Key Provisioning for Group Communication July 2021 * 'scope', with value the specific resource at the KDC that the Client is authorized to access, i.e., group or topic name, and role(s). This value is a CBOR byte string wrapping one scope entry, as defined in Section 3.1. * 'get_pub_keys', if the Client wishes to receive the public keys of the other nodes in the group from the KDC. 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. Note that including this parameter may result in a large message size for the following response, which can be inconvenient for resource- constrained devices. The parameter's value is either the CBOR simple value Null, or a non-empty CBOR array containing the following three elements. - The first element, namely 'inclusion_flag', encodes the CBOR simple value True. [CS: Maybe explained what this flag signifies, as I see it's true by default for this handler, and may not be for other handlers (It's explained much later)] - The second element, namely 'role_filter', is a non-empty CBOR array. Each element of the array contains one role or a combination of roles for the group identified by GROUPNAME. The Client indicates that it wishes to receive the public keys of all group members having any of the single roles, or at least all of the roles indicated in any combination of roles. For example, the array ["role1", "role2+role3"] indicates that the Client wishes to receive the public keys of all group members that have at least "role1" or at least both "role2" and "role3". - The third element, namely 'id_filter', is an empty CBOR array. If the Client wishes to receive all public keys of all group members, it encodes the 'get_pub_key' parameter as the CBOR simple value Null. The CDDL definition [RFC8610] of 'get_pub_keys' is given in Figure 6, using as example encoding: node identifier encoded as a CBOR byte string; role identifier encoded as a CBOR text string, and combination of roles encoded as a CBOR array of roles. Note that the array of roles 'role_filter' is non-empty for this handler, but this is not necessarily the case for other handlers using this parameter: if this array is empty, it means that the client is not filtering public keys based on roles. Palombini & Tiloca Expires 13 January 2022 [Page 20] Internet-Draft Key Provisioning for Group Communication July 2021 Also note that the array of node identifiers 'id_filter' is empty for this handler, because the joining node is not expected or capable to express a filter based on node identifiers at this point in time. Consistently, the 'inclusion_flag' element is set to the CBOR simple value True. However, the 'id_filter' array is not necessarily empty for the value of 'get_pub_keys' received by the handler of FETCH to ace-group/GROUPNAME/pub-key (see Section 4.1.3.1). Finally, the 'get_pub_keys' parameter MUST NOT have the arrays 'role_filter' and 'id_filter' as both empty, i.e., in CBOR diagnostic notation: [ bool, [ ], [ ] ]. Thus, if this parameter is received as formatted in that way, it has to be considered malformed. [CS: I understand that other handlers may use this parameter, but maybe it's better to focus its value for this handler; otherwise it becomes tedious to parse the information]. [SNIP] * 'control_uri', with value a full URI, encoded as a CBOR text string. If 'control_uri' is supported by the Client, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDC MAY use this URI to send CoAP requests to the Client (acting as CoAP server in this exchange), for example for individual provisioning of new keying material when performing a group rekeying (see Section 4.4), or to inform the Client of its removal from the group Section 5. [CS: So the above are KDC initiated? I think it needs to be clarified what mechanisms are expected to be initiated by KDC. If this uri is not present, how does the KDC rekey?] If the KDC does not implement Palombini & Tiloca Expires 13 January 2022 [Page 22] Internet-Draft Key Provisioning for Group Communication July 2021 mechanisms using this resource, it can just ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications (OPT9). In particular, this resource is intended for communications concerning exclusively the group or topic specified in the 'scope' parameter. [SNIP] If no public key is included in the 'client_cred' field, the handler checks if one public key is already associated to the received access token (see Section 4.3 for an example) and to the group identified by GROUPNAME. [CS: I assume the client can use different public keys for different groups, and KDC supports this] If an eligible public key for the Client is neither present in the 'client_cred' field nor already stored, it is RECOMMENDED that the handler stops the processing and responds with a 4.00 (Bad Request) error message. Applications profiles MAY define alternatives (OPT6). If all the verifications above succeed, the handler performs the following actions. * The handler adds the Client to the list of current members of the group. * The handler assigns a name identifier NODENAME to the Client, and creates a sub-resource to /ace-group/GROUPNAME/ at the KDC (e.g., "/ace-group/GROUPNAME/nodes/NODENAME"). * The handler associates the node identifier NODENAME to the access token and the secure session for the Client. * If the KDC manages the group members' public keys: - The handler associates the retrieved Client's public key to the node identifier NODENAME and to the access token. [CS: shouldn't this be better - (nodename, groupname, accesstoken, public key), or my assumption is invalid, one public key per client, not per group?] - The handler adds the retrieved Client's public key to the stored list of public keys stored for the group identified by GROUPNAME. If such list already includes a public key for the Client, but a different public key is specified in the 'client_cred' field, then the handler MUST replace the old public key in the list with the one specified in the 'client_cred' field. * The handler returns a 2.01 (Created) response, containing the symmetric group keying material, the group policies and the public keys of the current members of the group, if the KDC manages those and the Client requested them. [SNIP] * '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 three elements "Sequence Number Synchronization Method", "Key Update Check Interval" and "Expiration Delta", which are summarized in Figure 9. Application profiles that build on this document MUST specify the exact content format and default value of included map entries (REQ17). [CS: So these MUST be specified, but I am still unclear whether Key updates are push/poll based, e.g., there are places where it reads like it is KDC initiated. So, key update check interval is 0, for example, if it's always push-based?] Palombini & Tiloca Expires 13 January 2022 [Page 27] Internet-Draft Key Provisioning for Group Communication July 2021 +--------------+-------+----------|---------------------|------------+ | Name | CBOR | CBOR | Description | Reference | | | label | type | | | |--------------+-------+----------|---------------------|------------| | Sequence | TBD1 | tstr/int | Method for a re- | [[this | | Number | | | cipient node to | document]] | | Synchroniza- | | | synchronize with | | | tion Method | | | sequence numbers | | | | | | of a sender node. | | | | | | Its value is taken | | | | | | from the 'Value' | | | | | | column of the | | | | | | Sequence Number | | | | | | Synchronization | | | | | | Method registry | | | | | | | | | Key Update | TBD2 | int | Polling interval | [[this | | Check | | | in seconds, to | document]] | | Interval | | | check for new | | | | | | keying material at | | | | | | the KDC | | | | | | | | | Expiration | TBD3 | uint | Number of seconds | [[this | | Delta | | | from 'exp' until | document]] | | | | | the specified UTC | | | | | | date/time after | | | | | | which group members | | | | | | MUST stop using the | | | | | | keying material to | | | | | | verify incoming | | | | | | messages. | | +--------------+-------+----------|---------------------|------------+ Figure 9: ACE Groupcomm Policies * '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 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 (REQ22). [CS: so, there is an implicit admin group, which can receive this information. I assume this is pre-assigned, or is it in the token scope?] [SNIP] 4.1.3. ace-group/GROUPNAME/pub-key [SNIP] 4.1.3.1. FETCH Handler The FETCH handler receives identifiers of group members for the group identified by GROUPNAME and returns the public keys of such group members. The handler expects a request with payload formatted as a CBOR map, that MUST contain the following fields: * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with the following modification: - The element 'inclusion_flag' encodes the CBOR simple value True if the third element 'id_filter' specifies an empty CBOR array, or if the Client wishes to receive the public keys of the nodes having their node identifier specified in 'id_filter'. Instead, this element encodes the CBOR simple value False if the Client wishes to receive the public keys of the nodes not having the node identifiers specified in the third element 'id_filter'. [CS: so, to clarify, id_filter becomes an exclusion list if inclusion_flag is false? if it is true, and id_filter is not empty, it returns the pub_keys in the list, i.e., inclusion list? (Reading further, this seems correct. It may be explained earlier when inclusion_flag is first introduced] - The array 'role_filter' may be empty, if the Client does not wish to filter the requested public keys based on the roles of the group members. - The array 'id_filter' contains zero or more node identifiers of group members, for the group identified by GROUPNAME. The Client indicates that it wishes to receive the public keys of the nodes having or not having these node identifiers, in case the 'inclusion_flag' parameter encodes the CBOR simple value True or False, respectively. The array may be empty, if the Client does not wish to filter the requested public keys based on the node identifiers of the group members. Note that, in case both the 'role_filter' array and the 'id_filter' array are not empty: * If the 'inclusion_flag' encodes the CBOR simple value True, the handler returns the public keys of group members whose roles match with 'role_filter' and/or having their node identifier specified in 'id_filter'. * If the 'inclusion_flag' encodes the CBOR simple value False, the handler returns the public keys of group members whose roles match with 'role_filter' and, at the same time, not having their node identifier specified in 'id_filter'. Palombini & Tiloca Expires 13 January 2022 [Page 30] Internet-Draft Key Provisioning for Group Communication July 2021 Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter' and 'id_filter' MUST NOT be both empty. [CS: Why? Can't I ask to get all the public keys of nodes in this group, which has a public key? (I see that this is a GET request, on reading further, a forward pointer here?)] [SNIP] The handler MAY enforce one of the following policies, in order to handle possible node identifiers that are included in the 'id_filter' element of 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 (REQ16). * The KDC silently ignores those node identifiers. * 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. [CS: I think this is a wider policy e.g., how long does the KDC retain any information about the historical group members?] [SNIP] 4.1.4. ace-group/GROUPNAME/policies [SNIP] 4.1.5. ace-group/GROUPNAME/num This resource implements a GET handler. 4.1.5.1. GET Handler The handler expects a GET request. [SNIP] [CS: In general, in the SNIPPED text above, there is much repetition across different sections, in terms of format expected, group membership access control etc. Could that be said only once to apply to all resources, or all operations within a resource?] [SNIP] 4.1.6. ace-group/GROUPNAME/nodes/NODENAME This resource implements GET, PUT and DELETE handlers. 4.1.6.1. PUT Handler 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 NODENAME) for the group identified by GROUPNAME. Application profiles MAY also use this handler to rekey the whole group. It is up to the application profiles to specify if this handler supports renewal of individual keying material, renewal of the group keying material or both (OPT8). [CS: I am a bit puzzled that something that potentially is rekeying the whole group is done under NODENAME resource. On the other hand, POSTing the GROUPNAME adds a node to the group rather than rekeying the group. I would expect POSTing to ace-group/GROUPNAME/nodes would add a node instead. ] [SNIP] 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key This resource implements a POST handler, if the KDC stores the public key of group members. If the KDC does not store the public keys of group members, the handler does not implement any method, and every request returns a 4.05 Method Not Allowed error. 4.1.7.1. POST Handler The POST handler is used to replace the stored public key of this client (identified by NODENAME) with the one specified in the request at the KDC, for the group identified by GROUPNAME. [SNIP] 4.2. Retrieval of Group Names and URIs In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get update information from the KDC, the node can contact the KDC to request the corresponding group name and joining resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in Section 4.1.1.1. [SNIP] 4.3. Joining Exchange [CS: I feel this needs to come earlier in the draft] Figure 12 gives an overview of the Joining exchange between Client and KDC, when the Client first joins a group, while Figure 13 shows an example. Client KDC | | |----- Joining Request: POST /ace-group/GROUPNAME ------>| | | |<--------- Joining Response: 2.01 (Created) ----------- | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | Figure 12: Message Flow of First Exchange for Group Joining Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with PUB_KEY and POP_EVIDENCE being CBOR byte strings): { "scope": << [ "group1", ["sender", "receiver"] ] >> , "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY "cnonce": h'6df49c495409a9b5', "client_cred_verify": POP_EVIDENCE } Response: Header: Created (Code=2.01) Content-Format: "application/ace-groupcomm+cbor" Location-Path: "kdc.example.com" Location-Path: "g1" Location-Path: "nodes" Location-Path: "c101" Payload (in CBOR diagnostic notation, with KEY being a CBOR byte strings): { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200, "pub_keys": [ PUB_KEY1, PUB_KEY2 ], "peer_roles": ["sender", ["sender", "receiver"]], "peer_identifiers": [ ID1, ID2 ] } Figure 13: Example of First Exchange for Group Joining Palombini & Tiloca Expires 13 January 2022 [Page 40] Internet-Draft Key Provisioning for Group Communication July 2021 [SNIP] 4.4. Retrieval of Updated Keying Material When any of the following happens, a node MUST stop using the owned group keying material to protect outgoing messages, and SHOULD stop using it to decrypt and verify incoming messages. * Upon expiration of the keying material, according to what indicated by the KDC with the 'exp' parameter in a Joining Response, or to a pre-configured value. * Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC. * Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by the KDC, that the Client was not able to receive or decrypt. In either case, if it wants to continue participating in the group communication, the node has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.1.6.2. [CS: I feel the information in this section need to come before after the resources are introduced, but before the operation and parameter details are presented for each group. The message examples would be better appreciated right after all the parameters etc of the operation is introduced.] [SNIP] Alternatively, the re-distribution of keying material can be initiated by the KDC, which e.g.,: * Can make the ace-group/GROUPNAME resource Observable [RFC7641], and send notifications to observer Clients when the keying material is updated. [CS: Some of my questions earlier is answered here. I feel this should be said earlier] [SNIP] * Can act as a publisher in a pub-sub scenario, and update the keying material by publishing on a specific topic on a broker, which all the members of the group are subscribed to. [CS: This is not a good scenario for pub-sub, as the broker should not know the keys. The whole idea of the pub-sub profile is the protect the content of the messages from the broker. That means these keying materials should be encrypted, and hence, then, the distribution of that keying material ... becomes a recursive problem.] Note that these methods of KDC-initiated key distribution have different security properties and require different security associations. 4.5. Requesting a Change of Keying Material [SNIP] 5. Removal of a Node from the Group [SNIP] Furthermore, in case of forced eviction, the KDC removes the public key of the evicted node if the KDC keep tracks of that, and possibly removes the evicted node from the list of observers of the resource at ace-group/GROUPNAME (if observable). [CS: Why only "possibly"?] [SNIP] 6. Extended Scope Format [SNIP] The value of the 'scope' claim following the extended format is composed as follows. Given the original scope using a semantics SEM and encoded as a CBOR byte string, the corresponding extended scope is encoded as a tagged CBOR byte string, wrapping a CBOR sequence [RFC8742] of two elements. In particular: * The first element of the sequence is a CBOR integer, and identifies the semantics SEM used for this scope. The value of this element has to be taken from the "Value" column of the "ACE Scope Semantics" registry defined in Section 10.12 of this specification. Palombini & Tiloca Expires 13 January 2022 [Page 52] Internet-Draft Key Provisioning for Group Communication July 2021 When defining a new semantics for a binary scope, it is up to the applications and application profiles to define and register the corresponding integer identifier (REQ24). * The second element of the sequence is the original scope using the semantics SEM, encoded as a CBOR byte string. Finally, the CBOR byte string wrapping the CBOR sequence is tagged, and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format", defined in Section 10.11 of this specification. The resulting tagged CBOR byte string is used as value of the 'scope' claim of the access token. The usage of the extended scope format is not limited to application profiles of this specification or to applications based on group communication. Rather, it is generally applicable to any application and application profile where access control information in the access token is expressed as a binary encoded scope. [CS: Then should it be defined here in this profile or somewhere else?] [SNIP] 7. ACE Groupcomm Parameters [CS: Handy table] 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. Note that the media type application/ace-groupcomm+cbor MUST be used when these fields are transported. +=======================+======+================+==================+ | Name | CBOR | CBOR Type | Reference | | | Key | | | +=======================+======+================+==================+ | error | TBD | int | Section 4 | +-----------------------+------+----------------+------------------+ | error_description | TBD | text string | Section 4 | +-----------------------+------+----------------+------------------+ | scope | TBD | byte string | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | get_pub_keys | TBD | array / simple | Section 4.1.2.1, | | | | value null | Section 4.1.3.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 | +-----------------------+------+----------------+------------------+ Palombini & Tiloca Expires 13 January 2022 [Page 54] Internet-Draft Key Provisioning for Group Communication July 2021 | pub_keys_repos | TBD | text string | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | control_uri | TBD | text string | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | gkty | TBD | integer / text | Section 4.1.2.1 | | | | string | | +-----------------------+------+----------------+------------------+ | key | TBD | see "ACE | Section 4.1.2.1 | | | | Groupcomm Key" | | | | | Registry | | +-----------------------+------+----------------+------------------+ | num | TBD | int | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | exp | TBD | int | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | pub_keys | TBD | array | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | peer_roles | TBD | array | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | peer_identifiers | TBD | array | 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 | +-----------------------+------+----------------+------------------+ | sign_info | TBD | array | Section 4.1.2.1 | +-----------------------+------+----------------+------------------+ | gid | TBD | array | Section 4.1.1.1 | +-----------------------+------+----------------+------------------+ | gname | TBD | array of text | Section 4.1.1.1 | | | | strings | | +-----------------------+------+----------------+------------------+ | guri | TBD | array of text | Section 4.1.1.1 | | | | strings | | +-----------------------+------+----------------+------------------+ | kdcchallenge | TBD | byte string | Section 4.1.7.1 | +-----------------------+------+----------------+------------------+ Table 1 [SNIP] 9. Security Considerations [SNIP] That is, the KDC may not rekey the group at every membership change, for instance if members' joining and leaving occur frequently and performing a group rekeying takes too long. The KDC may rekey the group after a minimum number of group members have joined or left within a given time interval, or after maximum amount of time since the last rekeying was completed, or yet during predictable network inactivity periods. However, this would result in the KDC not constantly preserving backward and forward security. Newly joining group members could be able to access the keying material used before their joining, and thus could access past group communications. Also, until the KDC performs a group rekeying, the newly leaving nodes would still be able to access upcoming group communications that are protected with the keying material that has not yet been updated. [CS: I think the minimum number of group members should be just 1 if we are talking about secure group communication] [SNIP] 9.1. Update of Keying Material A group member can receive a message shortly after the group has been rekeyed, and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members. In the first case, the sender protects a message using the old keying material. However, the recipient receives the message after having received the new keying material, hence not being able to correctly process it. A possible way to ameliorate this issue is to preserve the old, recent, keying material for a maximum amount of time defined by the application. By doing so, the recipient can still try to process the received message using the old retained keying material. Note that a former (compromised) group member can take advantage of Palombini & Tiloca Expires 13 January 2022 [Page 57] Internet-Draft Key Provisioning for Group Communication July 2021 this by sending messages protected with the old retained keying material. Therefore, a conservative application policy should not admit the storage of old keying material. [CS: Could it be an option to resend the message with the new keying material? if the rekeying happened within a window] [SNIP] 10. IANA Considerations This document has the following actions for IANA. 10.1. Media Type Registrations [SNIP] Appendix B. Extensibility for Future COSE Algorithms [CS: Why not just use this format instead of reformatting sign_info_entry In section 3.3.1] As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future algorithms can be registered in the "COSE Algorithms" Registry [COSE.Algorithms] as specifying none or multiple COSE capabilities. To enable the seamless use of such future registered algorithms, this section defines a general, agile format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Post response, see Section 3.3.1. If any of the currently registered COSE algorithms is considered, using this general format yields the same structure of 'sign_info_entry' defined in this document, thus ensuring retro- compatibility. Palombini & Tiloca Expires 13 January 2022 [Page 73] Internet-Draft Key Provisioning for Group Communication July 2021 B.1. Format of 'sign_info_entry' The format of each 'sign_info_entry' (see Section 3.3.1) is generalized as follows. Given N the number of elements of the 'sign_parameters' array, i.e., the number of COSE capabilities of the signature algorithm, then: * 'sign_key_parameters' is replaced by N elements 'sign_capab_i', each of which is a CBOR array. * The i-th array following 'sign_parameters', i.e., 'sign_capab_i' (i = 0, ..., N-1), is the array of COSE capabilities for the algorithm capability specified in 'sign_parameters'[i]. sign_info_entry = [ id : gname / [ + gname ], sign_alg : int / tstr, sign_parameters : [ alg_capab_1 : any, alg_capab_2 : any, ..., alg_capab_N : any], sign_capab_1 : [ any ], sign_capab_2 : [ any ], ..., sign_capab_N : [ any ], pub_key_enc = int / nil ] gname = tstr Figure 30: 'sign_info_entry' with general format [SNIP] On Tue, Aug 24, 2021 at 5:52 PM Göran Selander <goran.selander= 40ericsson.com@dmarc.ietf.org> wrote: > Hi, > > Here is a review of ace-key-groupcomm-13. > > > General > === > > This draft provides a link between the ACE-OAuth authorization framework > (including its transport profiles) and specifications of communication > security in groups of constrained devices, e.g. the coap-groupcomm work > currently developed in CORE. The document is intended to support different > group communication schemes, but the details of those are defined in > separate “application profiles” such as draft-ietf-ace-key-groupcomm-oscore > (for Group OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This > draft instead defines a common interface to a KDC acting as RS in the > ACE-OAuth architecture, how to use this interface to perform various key > management operations, and requirements for such application profiles. > > As such, this draft is thus an “intermediary” specification, and its > usefulness will be determined by the application profiles which I've > glanced at but are not part of this review. > > While this approach seems reasonable from a structure point of view, I > have a question about abstracting the underlying communication in comment 1 > below. > > The content of the draft is quite elaborate and with detailed examples > which is good but also leads to my comment number 2. > > Now for the main comments: > > 1. How does this scale to large groups? > > Depending on application it may not be necessary to update keys during > join of new members, and depending on the dynamics of the members rekeying > may not be a major issue. But if it is a large group and all group members > need to be updated at joining or leaving then this may require a lot of > communication for which the underlying group communication may be helpful. > > For example, in case of a new member joining then a new group key or the > new node's public key may be distributed using broadcast/multicast and > protected with some existing group key. > > In case of rekeying a group key after a node has been evicted, a similar > method could be used if it was possible to apply some key hierarchy scheme > like e.g. LKH, i.e. distributing new keys corresponding to a path from the > evicted node to the root in a key hierarchy. > > Two sub-questions: > > a. Is it possible to extend the interface to make use of the underlying > group communication? > > b. Is it possible to apply this interface with a key hierarchy scheme? > > These features are not necessarily in scope of this draft, but it would be > good to understand if a specification of these features would be able to > use the interface defined here, or if some generalization is required in > which case that change may be considered already now. > > > 2. How would a "minimal" profile look like? > > The target setting for ACE in general and this draft in particular is > constrained devices and networks. Some parts of the draft give example of > thinking about lightweight aspects, but other parts are not at all > minimalistic and includes a large number of features, however in many cases > optional. > > It would be interesting to have a “minimal” example, where care has been > taken in trying to define a group setting such that the resulting messages > are as few and as small as possible (for a certain security level). The > same comment applies to code size and state machine: There are a number of > options and “nice to have” features, which if all implemented could have a > measurable impact on the footprint. > > The use of the word "minimal" is not intended in an absolute sense but to > target as little as possible and still provide authorized group key > functionality. Perhaps such an exercise makes more sense in an application > profile, such as draft-ace-key-groupcomm-oscore. But this draft may be > provide a partial answer by indicating what handlers to include (sec. 4), > what groupcomm parameters (sec. 7), what error ids (sec 8), etc. > > (This comment actually applies also to the transport profiles, which this > draft does not need to take responsibility for.) > > > > More detailed comments > === > > > I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST > Token” for the different message exchanges, respectively, quite confusing. > For a long time I thought the latter referred to the former. It is true > that the access token is carried with the method POST in the second > exchange, but I think that is irrelevant and would suggest to instead use > some other consistent terminology. For example, use “POST /token” and > “POST /authz-info” to refer to the exchanges, respectively. Alternatively, > call the latter “Token provisioning” or something similar without reference > to the actual method by which the token is provisioned. > > This applies in particular to: > > Figure 2 > “Token Post” > > Figure 3 > “POST Token” > > “3.3. Token Post” > > 3.3.1. > “an OPTIONAL parameter of the Token Post > response message “ > > 3.3.2 > “Token Post response” > > etc. > > > 4.1 > > Section 4.1 specifies the handlers, 20 pages. This is followed by how the > handlers are used 4.2 - 4.10, roughly one page per subsection. When reading > I ended up having two copies of the draft side by side looking at the > handler and its corresponding use. I'm not sure this is a problem, but > reading the handlers is more motivating after having read about how they > are used. There is a summary in the bullet list in 4.0 but this is merely a > forward reference and didn't make me do the mapping from handler to action > in my head. Maybe just move content such that 4.2-4.10 comes before 4.1 > (and then you can remove the bullet list in 4.0). > > > "It is REQUIRED of the application profiles of this specification to > define what operations (e.g., CoAP methods) are allowed on each > resource" > > It speaks of operations on each resource, but it does not say which > resources are mandatory to implement. Where is that written? > > > > 9. > > The security consideration speaks about different key update strategies. I > was looking for considerations when to not rekey in case of new member > joining a group. I would imagine in e.g. a building automation setting > where a new actuator device is added into a group it may not always be > necessary to renew the group key of existing actuators. This is in > particular assuming by the nature of security for actuations there are > already means in place to determine freshness etc. preventing misuse of an > old group key. > > > > > Nits > === > > > 3.1 > > s/Toid/“Toid” > s/Tperm/“Tperm” > > > 3.2 > > If this parameter is not present, the granted scope is equal to the one > requested in Section 3.1}. > > - remove the “}” > > > > 3.3. Token Post > > - - - > > “The CBOR map MAY additionally include the following > parameter, which, if included, MUST have the corresponding values: > > * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple > value Null to require information about the signature algorithm, > signature algorithm parameters, signature key parameters and on > the exact encoding of public keys used in the group.” > > > This seems to unnecessary duplicate information coming just after: > > > “3.3.1. 'sign_info' Parameter > > The 'sign_info' parameter is an OPTIONAL parameter of the Token Post > response message defined in Section 5.10.1. 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. > > - - - > > When used in the request, the 'sign_info' encodes the CBOR simple > value Null, to require information and parameters on the signature > algorithm and on the public keys used. > > The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as > in the request is given below. > > sign_info_req = nil” > > > 3.3.1 > > I got the impression from the text above that ‘sign_info’ is the name of > the parameter, but it turns out that the actual parameter is either called > “sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’ > encoding the CBOR simple value Null, which seems like a straightforward > assignment, there is actually no ‘sign_info’ parameter. This is a minor, > still slightly confusing. > > > 3.3.1 > > "This format is consistent with every signature algorithm currently > considered in [I-D.ietf-cose-rfc8152bis-algs], " > > > s/considered/defined > > > > 3.3.2 > > "(see the 'client_cred_verify' parameter in > Section 4)" > > Refer instead to 4.1.2.1 > > > > > 4.1.3.1 > > “in case both the 'role_filter' array and the 'id_filter' > array are not empty” > > > s/not empty/non-empty > > > 4.1.3.1 > > "Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter' > and 'id_filter' MUST NOT be both empty." > > replace with > > "Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter' > and 'id_filter' MUST NOT both be empty." > > > > > > 4.4 > A missing comma at the end of the following line: > > "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY > > > > Göran > > > > > On 2021-07-12, 18:16, "Ace on behalf of internet-drafts@ietf.org" < > ace-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication and Authorization for > Constrained Environments WG of the IETF. > > Title : Key Provisioning for Group Communication > using ACE > Authors : Francesca Palombini > Marco Tiloca > Filename : draft-ietf-ace-key-groupcomm-13.txt > Pages : 78 > Date : 2021-07-12 > > 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. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > Source for this draft and an issue tracker can be found at > > https://protect2.fireeye.com/v1/url?k=08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5&q=1&e=fd87b927-3fdc-4d5a-ab71-6248ac68bf5d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm > . > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
- [Ace] draft-ietf-ace-key-groupcomm-13 Göran Selander
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Cigdem Sengul
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Marco Tiloca
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Marco Tiloca
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Göran Selander
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Marco Tiloca
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Cigdem Sengul
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Marco Tiloca
- Re: [Ace] draft-ietf-ace-key-groupcomm-13 Cigdem Sengul