Hi Göran, Thanks for the follow-up!
As to the questions and open points from your latest mail, below I summarize the outcome from the 2021-09-14 ACE interim meeting. For convenience, they are aggregated into 3 macro-points.
1) Available operations to support.- The KDC is assumed to support everything defined here. Application profiles can rule out specific unneeded operations, or add more. - For the group members, we will clarify what is expected to be minimally supported and why that's the case or not. There will be a new requirement for application profiles to define if certain operations must be supported or can remain optional for group members.
2) Enhanced error responses. We'll clarify that:- The diagnostic text is optional and intended for deployments that involve human intervention. Otherwise it can certainly be skipped. The KDC is supposed to log error events anyway. - These messages mimic the same approach used by the main error responses of the ACE framework. - The integer Error IDs are a cheap hint for a device, to tell it better than what a too generic CoAP error response code can tell. - Error IDs defined here are all available for application profiles, which can define and register more of their own, as they find them useful.
3) Group rekeying based on one-to-many messages, e.g., over multicast. We will enable this, by adding the missing building blocks. These include:- New related parameters especially in the Joining Response, e.g., signaling of the used rekeying scheme and the multicast IP address to use. - Provisioning of the KDC's public key, whose general parts can be imported from key-groupcomm-oscore where this has been defined already. This comes from the need to sign one-to-many rekeying messages to ensure they are sent by the KDC.
Also, it should be possible to provide a high-level example in the new-to-be section dedicated to group rekeying, when discussing efficient approaches. Key Graph can be taken as a concrete rekeying scheme to make such example not too abstract.
Building on that example, application profiles can probably refine details, while still remaining high-level. For instance, the generic "node identifier" of key-groupcomm becomes the more specific "Sender ID" in key-groupcomm-oscore , if that information has to be conveyed in a rekeying message.
Something way more detailed, up to a precise message/data format to send on the wire, is very much dependent on the exact rekeying scheme used in the group, and is also likely affected by the exact application profile. I believe that that level of detail would require separate, dedicated specifications, that define a binding between a rekeying scheme on one hand, and with key-groupcomm together with one or more of its application profiles on the other hand.
Best, /Marco On 2021-09-14 10:57, Göran Selander wrote:
Hi Marco, Please find responses inline. On 2021-08-31, 18:10, "Marco Tiloca" <[email protected]> wrote: On 2021-08-24 18:52, Göran Selander wrote: > Hi, > > Here is a review of ace-key-groupcomm-13. > > > General > ===> 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. ==>MT Definitely the new group key material to use before completing the joining of the new member. As to the public key of the new group member (if there is one at all, depending on the member's roles), it's actually good to admit its provisioning _together_ with the group key material. It would spare other group members to perform dedicated retrieval traffic with the KDC just for that later on. This can be added to the last paragraph of Section 4.3. [GS: OK.] As to using "some existing group key", yes, this requires a separate set of administrative key material, possibly organized into a hierarchy whose root is the administrative group key (see also later comments). That's the key material used to protect rekeying messages at the application layer, and in principle unrelated to the secure communication protocol used in the group. [GS: Sure, I could have been more accurate and written "a key derived from some existing shared key". This can be done in different ways but since this draft is about rekeying for group communication in resource constrained settings, shouldn't the use of the existing secure group communication be defined here or in an application profile?] > > 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. ==>MT Yes. This is explicitly mentioned in Section 4.4, in the second bullet point after Figure 15. As above, this requires a separate set of administrative key material, possibly organized into a hierarchy whose root is the administrative group key (see also later comments). Also as above, that's the key material used to protect rekeying messages at the application layer, and in principle unrelated to the secure communication protocol used in the group. <== [GS: Thanks, I missed that. It seems inevitable for good scalability that at least the application profiles define this. More below.] > > Two sub-questions: > > a. Is it possible to extend the interface to make use of the underlying group communication? ==>MT It should already be able to accommodate it. In particular: * In Section 4.4, the second bullet point after Figure 15 already mentions this possibility. An application profile or a separate specification that builds on and extends it would have to define the exact rekeying scheme to use and its message formats. * At the end of Section 4.1.2.1, it is defined that the Joining Response can include an optional parameter 'mgt_key_material'. In case of rekeying schemes more advanced than a basic point-to-point approach using pairwise security associations, this parameter provides a group member with the administrative key material _it_ needs to have to participate in a group rekeying. For example, if a hierarchy-based scheme is used, the parameter specifies the administrative keys in the key tree from the leaf node associated to the group member all the way up along the path from that leaf node to the root (which is the administrative group key shared by all the group members). * In Section 4.4, the third bullet point after Figure 15 refers to a local "control" resource at a group member, where the KDC can send requests such as rekeying messages. The group member can provide the KDC with the URI of such a local resource when joining the group, in the 'control_uri' parameter of the Joining Request. This is more generally intended as a resource where the KDC can reach the group member with a request, and is potentially usable for several administrative operations, including a group rekeying. In the previous, second bullet point, it can be explicitly mentioned that this resource can also be the target of a group rekeying request sent over multicast. Note that 'control_uri' may indicate an administrative "root path", that the group member determines as relevant for that security group. I would imagine requests for different administrative tasks to target different sub-resources identified by well-known path segments under that path. [GS: Right, so there are components defined which can be used for this purpose.] There are still two missing things, though. * A group member would need to know the multicast address where the KDC sends group rekeying messages. This might also be provided as an additional parameter in the Joining Response. Several versions ago, we proposed to include this in draft, but the idea was dismissed to keep things simple. Should we revisit this and add an optional parameter of this kind in the Joining Response? [GS: If needed for simple configuration, then I'd say "yes", see below.] Note that this goes hand-in-hand with _requiring_ a joining node to provide also the URI of a local control resource, in the 'control_uri' parameter of the Joining Request. Hence, it becomes (even more) important for the joining node to know as much as possible about how the group works (e.g. by means of early discovery), before attempting to join it by sending the Joining Request. * When joining the group, a node also needs to know the exactly used group rekeying scheme. The easiest way I see to signal it is defining one more integer-valued ACE Groupcomm Policy (see Figure 9 in Section 4.1.2.1) to be specified in the optional 'group_policies' parameter of the Joining Response. Its value would indicate the exact rekeying scheme (and we would need a new IANA registry). If the KDC does not say anything about that, the joining node assumes that a group rekeying is performed point-to-point, thus relying on the pairwise communication channel it has with the KDC. <== [GS: Thanks for elaborate response. Maybe what I'm missing is a simple example of how to apply the different components of this draft for using a key hierarchy scheme (again, could go into a profile). On the latter topic of what information needs to be provided before joining, some configuration data can be assumed to be pre-configured. To re-iterate: I'm not looking for a "complete" scheme which takes into account all information flows in all possible key distribution schemes, but making sure that there is a simple deployment which scales to very large groups.] > > b. Is it possible to apply this interface with a key hierarchy scheme? ==>MT Yes, it is totally up to the application profile and what it defines. The answer above should already give more practical details on what we have and what seems to be still missing. <== > > 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. ==>MT Agree. The draft key-groupcomm-oscore is defining in detail a simple, point-to-point approach. Based on a comment above, it can be extended so that, in case of rekeying upon joining of a new member, the rekeying messages include also the public key and Sender ID of the new node (if this is not a Monitor). More generally, a multicast-based approach (e.g. relying on key hierarchy) should be totally possible to separately define and use, once some general aspects mentioned in the comments above are finalized here in key-groupcomm to be inheritable in an application profile. <== [GS: OK! Any thoughts on where to put such an example?] > > > 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. ==>MT I try to reply separately on each of the affected aspects mentioned above. * The handlers as such (Section 4) run at the KDC, which is not intended to be constrained. So, we defined the KDC as expected to offer the full interface specified in Section 4.1. I can imagine an application profile that really does not need a particular subset of handlers to declare them as not to be implemented, possibly under certain conditions. Thinking of a group member, I can imagine as important to have minimally implemented the logic for: FETCH on ace-group/ - To retrieve the group name and joining URI from the specified group identifier. POST/GET on ace-group/GROUPNAME/ - To join the group (POST) and retrieve the current group key material as group member (GET). GET/FETCH on ace-group/GROUPNAME/pub-key - To retrieve the public keys of all the other group members (GET) or only of some by filtering (FETCH). Admittedly, the latter might be sacrificed, but it allows to reduce the number of transferred public keys a lot. GET on ace-group/GROUPNAME/num - To retrieve only the current version of the group key material. DELETE on ace-group/GROUPNAME/nodes/NODENAME - To leave the group. Instead, the following logic might be omitted in the implementation of a minimal group member: GET on ace-group/GROUPNAME/active - To check the status of the group GET on ace-group/GROUPNAME/policies - To retrieve the group policies. Thus, they would be obtainable only when joining the group with a POST on ace-group/GROUPNAME/ (see above). GET/PUT on ace-group/GROUPNAME/nodes/NODENAME - GET is for obtaining the current group key material plus the "individual node key material" (e.g., the Sender ID in the Group OSCORE case). The former can be obtained with a GET on ace-group/GROUPNAME/ (see above). The latter would not be possible to re-obtain as group member, thus expecting the group member to just remember that information, whose possible change happens in a synchronized way with the KDC anyway (see right below). - PUT is requesting new "individual node key material" (which can result in the KDC providing new one, or rekeying the group, or both things together). This can also be sacrificed, so that a group member needing a new individual node key material would re-join the group with a POST on ace-group/GROUPNAME/ (see above). POST on ace-group/GROUPNAME/nodes/NODENAME/pub-key - To upload a new public key of its own. This can be sacrificed, assuming that a group member does not change its public key during its membership. [GS: This type of discussion makes sense to me and I think it should be somewhere in the draft. The specification of exactly what of these to support is not part of this draft, but could go into an application profile, or some "compliance" document used for a particular deployment.] * About the Error IDs (Section 8), error responses will be sent anyway in case of errors at the KDC. The group members can of course not understand those error IDs. Also, based on the third from last paragraph in Section 4.0, the accompanying textual 'error_description' is already optional. Maybe it can help to: - Remove the parameter 'error_description' altogether; or, even more aggressively, - Make it just optional for the KDC to use these extended error responses with content format application/ace-groupcomm+cbor and payload the CBOR map with 'error' and 'error_description'. Thoughts? [GS: I think the focus should be on what actions follow from the error message, either autonomous or by humans. Detailed error codes can make sense for these settings when there are different autonomous actions that can follow from the errors. In case the errors anyway needs to be resolved by a human, a human readable diagnostic message could be an alternative. Having said this, it is not clear to me what can be predicted about deployment of a particular profile of this draft. One question to ask is if the error semantics should be left more to the profiles or does the current error codes have value for intended profiles?] * About the ACE Groupcomm Parameters summarized in Section 7), most of them are required or practically required. Some of them can be conditionally not supported, e.g. by particular group members. Trying to have a first classification below: Must be supported: - 'scope', 'gkty', 'key', 'num' and 'exp', as related to the group in question and the retrieval of its key material. - 'gid', 'gname' and 'guri', as required for FETCH to /ace-group . - 'pub_keys' and 'peer_identifiers', since public keys are sooner or later going to be retrieved, accompanied by the node identifiers of the corresponding nodes. Practically must be supported: - 'get_pub'keys' is practically necessary, except for the inconvenient and undesirable behavior where: i) a group member does not ask for the other group members' public keys upon joining; and ii) later on, the group member only retrieves the public keys of all group members with a GET to ace-group/GROUPNAME/pub-key (i.e., never by using FETCH). Conditionally not supported - 'client_cred', 'cnonce' and 'client_cred_verify' are not needed to be supported by a node if this does not have a public key of its own that it uses in the group. - 'kdcchallenge' is not needed to be supported by a node if this does not have a public key of its own that it uses in the group, or if it does not post the Token to /authz-info at the KDC. The PoP input share N_S of the KDC has thus to be determined differently and it's up to the profiles to define how (see REQ21). - 'pub_keys_repos' is not needed to be supported by a node if this does not have a public key of its own that it uses in the group, or if it does not store the public key in a repo to point to with this parameter. - 'group_policies' might be sent by the KDC anyway. It may not be supported by a node if it is already aware of all group policies. These may include a particular group rekeying scheme (see comment above). In other words, it may not be supported by a node that never joins a group without knowing its group policies in advance. - 'peer_roles' goes hand-in-hand with 'pub_keys' and 'peer_identifiers'. Generally, it should be fine that it is not needed to be supported by a node if this does not have to care of the exact role of the node associated to a retrieved public key. - 'control_uri', is already optional to include in the Joining Request. However, its support is preferable to enable even point-to-point group rekeying initiated by the KDC. On the other other hand, it would rather become necessary to support, if the group uses an advanced key management scheme. In such a case, a node willing to join such a group has to support this parameter, in order to indicate the URI of a local resource to the KDC. - 'mgt_key_material' would be sent by the KDC anyway, if the group uses an advanced key management schemes. In such a case, a node willing to join such a group has to support this parameter. In other words, it may not be supported by a node that never joins a group which uses an advanced group key management scheme. May generally be not supported: - 'error' and 'error_description', see comment above. - 'ace_groupcomm_profile', as already defined optional in Section 4.1.2.1. Would this kind of reasoned classification help? [GS: Yes, I think some reasoning or classification would be instructive.] <== > > (This comment actually applies also to the transport profiles, which this draft does not need to take responsibility for.) ==>MT Right, to be kept in mind for the profiles too, considering the additional profile-specific parameter that they can add. <== > > > > 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. ==>MT Right, I can replace this occurrences of "Token Post" with "Token Uploading". [GS: Good. (Perhaps consider also other synonyms to "uploading" ...)] The use of "POST /token" and "POST /authz-info" is limited to Figures 2 and 3, where it should be appropriate. <== > > > 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). ==>MT The issue is that each example in Sections 4.2-4.10 also refers to the corresponding handler description, which defines also the payload format for that operation. In particular, all the ACE Groupcomm parameters are introduced in Section 4.1. An example shown before that risks to not say that much. I think that a middle ground can be the following, and it should also be aligned with and address similar comments that Cigdem gave in her review [1]. 1) Merging the points from the bullet list of Section 4.0 into the corresponding resource description of Section 4.1, while still preserving the forward pointers. This can make it easier to map between actions from a client point of view with resources at the KDC, even though no details have been introduced yet. 2) Separately moving each current Section 4.2-4.10 right after the corresponding handler section, now numbered 4.1.x.y. After that, a better structuring can also be achieved, so that: - Section 4.1 is renamed "Overview of the Interface at the KDC". - The following sections lose one numbering level, e.g. current 4.1.1 "ace-group" becomes 4.2 "ace-group". - Each Section 4.x can be about a KDC resource. This in turn includes 4.x.y with a handler description for resource x, followed by 4.x.y.z with the example for handler y or resource x (taken from current Sections 4.2-4.10). That is: 4. Keying Material Provisioning and Group Membership Management 4.1 Overview of the Interface at the KDC 4.2 ace-group 4.2.1 FETCH handler 4.2.1.1 Example <Content from current Section 4.2> 4.3 ace-group/GROUPNAME 4.3.1 POST handler 4.3.1.1 Example <Content from current Section 4.3> 4.3.2 GET handler 4.3.1.1 Example <currently missing> ... How does it sound? [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fgv_uRo2Y45jqOLJghVSbAARWky0%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C060e402a92954dbe7a9608d9775dbeb5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637672066803513332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pI%2FXmRkFgV6dR4PbqKzxdfJLb%2BzuXn8uV%2Binhb2fd8U%3D&reserved=0 <== [GS: Sounds good!] > > > "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? ==>MT Building on a comment above, the KDC is supposed to implement all these resources (and possibly add more if needed and defined by a specific application profile). As discussed above, a minimal group member may however not need to implement the logic to use some of those resources. This requirement was more intended to require application profiles to produce something like Figure 2 of ace-key-groupcomm-oscore , see its Section 5.5 "Admitted Methods". <== [GS: OK] > > > > 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. ==>MT We can add something along these lines, especially on when it might be acceptable to not ensure backward security (or anyway not rigorously upon every single new joining). Ultimately, it is up to the specific application to decide and define policies for the KDC to enforce. Besides the freshness aspects you mention, this is more about accepting that the newly joined node would have access to communications in the group prior its joining, if it has recorded such exchanged messages. <== [GS: OK] > > > > 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” ==>MT Ok, we can remove the redundancy and also be more explicit, pointing to the exact format 'sign_info_req' or 'sign_info_resp' used in the message in question. <== > > > 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. ==>MT Yes, there is only one actual parameter, 'sign_info', and we want a single CBOR abbreviation registered for it to use in the payload map. Using the different _req and _resp versions in Section 3.3.1 is just a way to make a hard distinction between the request and response case. It might help to improve the CDDL definition, i.e.: sign_info = sign_info_req / sign_info_resp sign_info_req = nil ; used in a request sign_info_resp = [ + sign_info_entry ] ; used in a response ... [GS: Yes, that reads better to me] Göran
-- Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
