Hello Jim, The latest version -06 submitted today should have addressed all your comments below.
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06 Please, see replies inline. Thanks a lot for this review! Best, /Marco On 2020-03-15 22:43, Jim Schaad wrote: > Forgot to cc the group > > -----Original Message----- > From: Jim Schaad <[email protected]> > Sent: Sunday, March 15, 2020 1:48 PM > To: '[email protected]' > <[email protected]> > Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05 > > * Introduction: In para 2, the second sentence needs to be re-written. If > you remove the subclause, then you get "This relies on a Group Manager where > members exchange CoAP messages secured with Group OSCORE." Which is wrong. ==>MT We have rephrased the text as: “This relies on a Group Manager, which is responsible for managing an OSCORE group, and enables the group members to exchange CoAP messages secured with Group OSCORE.” <== > > * Section 2 - The following is a problematic statement " All communications > between the involved entities rely on the CoAP protocol and MUST be > secured." For something like MQTT you want to be able to do it in JSON/HTTP ==>MT Rephrased as: “All communications between the involved entities MUST be secured.” <== > > * Section 2.2 - I think it might be worthwhile in para 3 to give the reason > for needing a new group identifier - This is because of the conflict in name > between group identifier of OSCORE and group identifier of > ace-key-groupcomm. You have not yet stated that they are different things. ==>MT Now the first bullet point on the Gid clarifies that it is OSCORE-related information, and highlights the difference from the group name in Section 1.1. <== > > * Section 3.1 - I think I said this before but ["requester", "monitor"] > seems to be a bit of an oxymoron. Anybody who is either a requester or a > responder can be a monitor without advertising the fact. ==>MT We have removed this combination of roles. It’s true that if the joining node is requester or requester+monitor , it has in either case to provide its own public key and may want to retrieve the other members’. So there is no difference in terms of key provisioning either. <== > > * Section 3.1 - The table in figure 1 is currently not usable due to the > definition of scope in ace-key-groupcomm. ==>MT This should now be fine, since Section 3.1 of ace-key-groupcomm is admitting flexibility in the encoding of group name and roles, left to the application profile as per REQ1 and REQ2. In this document, REQ1 is defining group names to be encoded as CBOR text strings, while REQ2 is defining roles to be encoded as abbreviating CBOR integers. <== > > * Section 3.1 - The framework allows for the scope and the audience to be > implicit for an endpoint that is only doing one thing. Are you sure you > want to eliminate that option? ==>MT Right. In the revised text, we don’t mention ‘audience’ anymore, while we detail the content of ‘scope’ if present. <== > > * Section 4 - I think you probably want to justify the reason for changing > the base name of the resource. Also the same comments that I made in > ace-key-groupcomm about registering as a well-known are going to exist if > you really want it to be fixed. ==>MT That was an oversight. The segment group-manager/ was supposed to be group-oscore/ , as in the operations described in the following sections. On the second part of the comment, this resource just inherits the Interface Description (if=) Link Target Attribute value “ace-group” introduced in Section 4.1 of ace-key-groupcomm and registered in Section 8.9 of that same document. <== > > * Section 5.2 - scope should not be a mandatory element in the request - it > is implicit in the path name and the scope in the token. ==>MT Ok, we have made scope optional in the joining request, by simply not mentioning it anymore. Then the MAY contain from ace-key-groupcomm applies here. The last path segment is fine for the GM to understand the group at hand, then the corresponding allowed roles are also retrievable from the stored token claims. <== > > * Section 5.2.1 - Is this a place where we need to look at replay? I don't > think so because of the cryptographic wrapper, but we need to have that > discussion in the document. Which indicates a pointer from this section to > where that discussion is. ==>MT At the end of the section, we have added a pointer to the new Section 17.3, whose content was already included as part of Section 17.2. <== > > * Section 5.4 - cs_alg should refer to the IANA registries not the COSE > document - what if there is a new signature algorithm, like say RSA. ==>MT Done. <== > > * Section 6 - is it an error for a monitor to provide a public key? After > all an invalid signature would not need to be checked. To make life even > more fun, does the rsnonce need to be provided on a token post? ==>MT We have added text under the first bullet point, to explain that it is not an error, and the Group Manager just silently ignores ‘cnonce’, ‘client_cred’ and ‘client_cred_verify’, in case the joining node has “monitor” as single authorized role. As to the second question, we have also added some text in Section 5.1. That is, when responding to a Token POST, the Group Manager does not need to return 'kdcchallenge' (was rsnonce) to the client, if ‘scope’ in the posted Access Token indicates only the role “monitor” or only the role “verifier”, for each of the specified groups. The final choice to take advantage of this optimization is left to the implementor. <== > > * Section 8 - For bullet 2.a - Is there a reason why this does not do the > rekey and return the new key material rather than returning an error? ==>MT Ok, we have rephrased the text as: “The Group Manager rekeys the OSCORE group. That is, the Group Manager generates new group keying material (see Section 16) and replies to the group member with the same group rekeying message defined in Section 16, providing the new group keying material. Then, the Group Manager rekeys the rest of the OSCORE group, as discussed in Section 16.” <== > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
