Hello Peter, Thank you very much for your review! Please, find our answers in line.
We took into account your comments for producing the latest version of the draft [1]. Best, /Marco [1] https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-04 On 2018-04-19 11:36, peter van der Stok wrote: > Hi authors, > > Below comments on the draft-tiloca-ace-oscoap-joining-03. > The draft seems to be pretty clear, but then, I did not try to > implement it. > > Comments on details, typos, structure, and questions are mixed > together in reading sequence. > > title: I expect draft-tiloca-ace-oscore-joining (oscoap is in the past) > [MT] Indeed, however we would need to submit a new version -00. > page 3 section 1. dtls-authorize and oscore-profile are mentioned > quite prominently here, but almost not used elsewhere in the draft > (section 6), and only informative. suggest to remove here. [MT] We have removed the references from this paragraph, and made dtls-authorize informative. However, we think to keep oscore-profile normative, due to a number of COSE Key parameters used in the Join Response (Section 4.2) and defined in the OSCORE profile document. > > section 1.1 The phrase "message exchanges .... useful terminology" may > go for me. (mentioned in authz and others already). > Is reference to oAuth 2.0 not sufficient, ace-actors is not really > needed IMO. [MT] We removed the sentence and the following reference to ace-actors. > > I miss Group Manager in the terminology. here relation with RS can be > mentioned, not needed in section 2. [MT] The paragraph pointing at OSCORE and oscore-groupcomm has been extended as follows: "These include the concept of Group Manager, as the entity responsible for a set of groups where communications are secured with OSCORE. In this specification, the Group Manager acts as Resource Server." > > Section 2 bullet 3 is quite complex text: > Suggestion: > The Authorization Server (AS) authorizes joining nodes to join .... > The AS MAY release access tokens for other purposes than accessing > join resources; for example: to release...... > of OSCORE groups [MT] We took into account your suggestions and rephrased the text. > > Page 5 > Is paragraph "All communication ...... ACE Framework [authz]" not > almost identical to > "communications between ..... this specification". If not, > reformulation is clearly needed. > [MT] We reformulated as follows: i) a first single-sentence paragraph points at secure communication based on CoAP; ii) a second paragraph on the secure communication required between joining node and Group Manager; and iii) a third paragraph about secure communication with the AS, either between the AS and the joining node or between the AS and the Group Manager. > page 5 point 1. suggestion for last phrase: With the response from the > AS, the joining node starts or continues a secure channel with the > Group Manager. [MT] We rephrased the text as: "The joining node will start or continue using a secure communication channel with the Group Manager, according to the response from the AS." > point 2 Collapse phrase 2 and 3 to: "Then, a joining node must > establish .....first time". May be add a reference to DTLS or other > recommended alternatives? > [MT] We rephrased the text as: "After that, a joining node must have a secure communication channel established with the Group Manager, before starting to join an OSCORE group under that Group Manager (see Section 4). Possible alternatives to provide a secure communication channel include DTLS [RFC6347] and OSCORE [I-D.ietf-core-object-security]." > point 4 in the OSCORE group -> with the OSCORE group members. > [MT] We rephrased it as "with the other members of the OSCORE group". > Suggest a point 5 to say that the secure channel is maintained for > between JN and GM [MT] Done. > > Section 3 is about JN to AS but mentions secure channel between JN and > GM. That is confusing, because I expect text about secure channel > between JN and AS. > I suggest to remove the discovery with the aid of resource-directory, > or add more text and specify a resource-type rt=) for the AS. > [MT] We have rephrased to put more focus on the exchange between JC-AS. Also, we removed the text pointing at the discovery based on the Resource Directory. > section 3.1 under scope parameter first *: I failed to find the > "dynamic" component of the scope parameter in [key-groupcomm] > [MT] Sorry for the confusion. What is dynamic, or actually variable, is not the "scope" parameter and its size, but part of the value of the actual Gid associated to the group. This is to admit Gid formats with multiple parts, some of which are dynamic in value, such as the case of Group Prefix and (variable) Group Epoch (see Appendix C of oscore-groupcomm). [MT] We have rephrased the second sentence as: "The value of this identifier may not fully coincide with the Gid value currently associated to the group, e.g. if the Gid is composed of a variable part such as a Group Epoch (see Appendix C of [I-D.ietf-core-oscore-groupcomm])." > get-pub-keys. I wonder why you want to separate the public key storage > from the GM. What is the operational advantage?; I only see added > complexity. > [MT] The oscore-groupcomm document defines a "broad interface" where public keys of group members can alternatively be stored at a separate trusted repository other than the Group Manager. However, oscore-groupcomm does recommend that the Group Manager acts as public key store (see its Section 6). [MT] To keep consistency, we are preserving both the same possibilities also in this document. Do you think that this ACE-based approach should explicitly be limited to the Group Manager as public key store? [MT] We have anyway removed the get_pub_keys parameter from the Authorization Request, also based on a discussion with Jim where we agreed that the AS has no actual reason to know about this specific wish from the joining node. > section 3.2 "The AS is responsible.....Group Manager" I don't > understand this phrase. > [MT] Now rephrased as: "The AS is responsible for authorizing the joining node to join specific OSCORE groups, according to join policies enforced on behalf of the respective Group Manager. > The "exp" parameter; it MUST be present and then is out of scope? > [MT] That was ambiguous, we rephrased it to be more aligned with Section 4.2.2 of RFC6749. What is out of scope if defining alternative means usable instead of "exp", hence required to be mandatory. > The phrase "in case the value......include the "scope" parameter" is > difficult to read. > I suggest: The AS must include the "scope" parameter in the response, > when the returned value of the response differs from the one in the > request. (or anything shorter) > [MT] We took into account your suggestions and rephrased the text. > section 4 page 7 > /what specified/ what is specified/ > [MT] Fixed. > section 4.2 page 8 > /yields to a positive/yields a positive/ [MT] Fixed. > > section 5 > Again why separate key storage > [MT] See reply to the comment above. > first bullet: IMO, it does not hurt to provide the public key, when > already known; specifying conditions in the protocol increases the > probability of errors. (Others may have different opinions given the > need of payload reduction) > [MT] Good point to consider. We have rephrased the last sentence as: "In this case, the joining node may not provide again its own public key to the Group Manager, in order to limit the size of the join request." > page 11 > "Before sending the join response .... this specification" suggest to > move this phrase to section 6. > [MT] Done, now placed right before the last paragraph of Section 6. > section 6. I suggest to add the reference to oscore-groupcomm when > referring to the (sections) or (appendix). > [MT] Done. > Hope this helps, > [MT] It definitely does, thanks a lot again! > Peter -- Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
