Re: [Ace] Review of draft-ietf-ace-key-groupcomm-oscore

[Marco Tiloca <[e-mail]>]

Hi Ludwig,

Thank you very much for your review! We have addressed your points in
the recently submitted v -03.

https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-03

Please, see our replies inline below.

Best,
/Marco

On 7/22/19 1:14 PM, Ludwig Seitz wrote:
> Hello Marco, Jiye, Francesca,
>
> I have read draft-ietf-ace-key-groupcomm-02 and I have a few comments
> for you:
>
> ==
>  1.1
> "The URI of a join resource is fixed."
>
> How can that be a requirement? The Group Manager might also be a
> mobile unit that changes address as it moves through different networks.
> Perhaps rephrase to "The URI-Path of a join resource is fixed"?

<MT>
Right, we in fact meant URI-Path.

Note that "join resource" has been renamed as "group-membership
resource", consistently with what planned for other related documents.
The joining process itself does not change.
</MT>

>
> ==
> 1.1
> "Monitor: ... This corresponds to the term "silent server" used in
> [I-D.ietf-core-oscore-groupcomm]."
>
> Any special reason for defining an separate equivalent term? Otherwise
> this only makes the set of documents harder to read.

<MT>
Yes, the reason is using the word "server" only for the ACE AS and RS,
while avoiding it for roles of nodes in the OSCORE group, that would
probably create more confusion.
</MT>

>
> ==
> 2.
> "To this end, the AS must signal the specific transport profile to
> use, consistently with requirements and assumptions defined in the ACE
> framework [I-D.ietf-ace-oauth-authz]."
>
> Note that in the ACE framework the AS does not have the obligation to
> signal the profile, since the assumed base-case is that the profiles
> are pre-configured and well-known in most constrained applications
> (this is an update from previous versions of the ACE framework).
>

<MT>
Right, we have relaxed the "must" to "MAY", and mention the most common
case of pre-configured profile usage.
</MT>

> ==
> All document: Update references to OSCORE to point to RFC 8613

<MT>
Done.
</MT>

>
> ==
> 2.
> "2. The joining node transfers authentication and authorization
> information to the Group Manager by posting the obtained Access Token
> (see Section 4)."
>
> Although it is explained in section 4 you might want to mention
> already here _where_ the information is POSTed (or replace "posting"
> with "sending")

<MT>
Done.
</MT>

>
> ==
> 2.
> "5.  The joining node and the Group Manager maintain the secure
> channel, to support possible future communications."
>
> Maintaining such a channel is costly in terms of memory, is that
> really a requirement?
>
> Also in the case of object security, speaking of a 'channel' is
> misleading.

<MT>
Sure, it is very much expected to be used for key management operations,
e.g. asking the GM for new keys, unsolicited (group) rekeying and so on.
We clarified this at the end of step 5.

We have replaced "channel" with "association".
</MT>

>
> ==
> 3.2
> "Also, the 'profile' parameter ..."
>
> See previous comment on profile being optional in the ACE framework

<MT>
Now fixed, also consistently with the other related comment above.
</MT>

>
> ==
>
> 4.
> "the Access Token post"
>
> I don't think this term is well-understood in general. I'd suggest
> removing it with something less REST-centric for the uninitiated
> reader, like e.g. "the sending of the Access Token to ..."

<MT>
Done.
</MT>

>
> ==
> 4.1
> " Note that the CBOR map specified as payload of the 2.01 (Created)
>    response may include further parameters,"
>
> Note that the ACE framework does not specify this response payload to
> be a CBOR map. Please explicitly state here that you are deviating
> from the default payload format in the ACE framework.

<MT>
We added this clarification at the end of the above different paragraph
starting with: "The payload of the 2.01 (Created) response is a CBOR map".
</MT>

>
> ==
> 4.2
> "In case the joining node knows the encoding of public keys in the
> OSCORE group, as well as the countersignature algorithm and possible
> associated parameters used in the OSCORE group, the included public
> key MUST be in a consistent format. "
>
> What is a "consistent format"? Please rephrase to be more specific.
> Or did you mean "compatible format"?

<MT>
We have rephrased it as "MUST be compatible with those criteria"
mentioned right above. Also, we have further clarified what has to match.
</MT>

>
> ==
> 4.3
> "That is, the public key has to be encoded as  expected in the OSCORE
> group, and has to be consistent with the counter signature algorithm
> and possible associated parameters used in the OSCORE group."
>
> What is "consistent with the ... algorithms and ... parameters"?
> Did you mean "compatible"?

<MT>
Yes, just replaced "consistent" with "compatible", here and in the rest
of the document.
</MT>

>
> ==
> 4.3
> "The 'profile' parameter MUST be present and has value
> coap_group_oscore_app (TBD), which is defined in Section 9.3 of this
> specification."
>
> See comments on 'profile' before.

<MT>
This is different, it's an application profile indicated by the GM to
tell the joining node what the keying material is intended for.

It is not indicating a transport profile (e.g., the OSCORE profile)
communicated by the AS when requesting an Access Token.
</MT>

>
> ==
> 6.
> "In this case, the joining node MAY not provide again its own public
> key to the Group Manager,"
>
> This could be misunderstood to mean "MAY NOT ...", how about
> rephrasing this to: "MAY choose not to provide ..." ?
>

<MT>
Done (now current Section 5).
</MT>

> ==
> 7.
> "When doing so, the Group Manager MAY take a best effort to preserve
> the same unchanged Sender IDs for all group members"
>
> This is incorrect use of requirements language. This 'MAY' can not be
> tested and the arguments for claiming conformance to this requirement
> would be quite diffuse. I suggest to require maintaining the Sender
> IDs. Why should the GM change them in the first place?
>
>

<MT>
(Now current Section 13)

As agreed at IETF 105, we have changed it to "Also, the Group Manager
MUST preserve the same ... ".

As to the Group Manager that may more generally end up changing the
Sender ID of a single group member, this is described in current Section
7, as for the reason and the way it happens.
</MT>


<MT>
Thank you very much again for your review!
</MT>

> Regards,
>
> Ludwig
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se