Re: [Ace] ace-oscoap-joining comments

[Marco Tiloca <[e-mail]>]

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: [phone]
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.